R – CruiseControl.NET: Displaying generated files as part of the build history

I unfortunately cannot answer all of your points, but let me start with this one:

• Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?

The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.

You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.

Re:

• Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?

I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).

Ever thought about using preprocessor commands?

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">

    <cb:define name="project.template">
        <project name="$(project.name)">
            <workingDirectory>D:\Integration\working\$(project.name)</workingDirectory>
            <artifactDirectory>D:\Integration\artifacts\$(project.name)</artifactDirectory>
            <state type="state" directory="D:\Integration\state\$(project.name)" />
        </project>
    </cb:define>

    <cb:project.template project.name="MyProject1" />

    <cb:project.template project.name="MyProject2" />

</cruisecontrol>