R – way to specify one artifactsDirectory for the whole site in CruiseControl.Net

continuous integrationcruisecontrol.net

so from what i can tell, you have to specify artifacts and working directory per project, every time.

I guess I'm looking for a way to move the cc.net project name folder to other than where the server was launched from, so that I can do something like:

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

    <!-- something like this should exist
    <baseDirectory>D:\Integration</baseDirectory>
    -->

    <project name="MyProject1">
        <workingDirectory>D:\Integration\working\MyProject1</workingDirectory>
        <artifactDirectory>D:\Integration\artifacts\MyProject1</artifactDirectory>
        <state type="state" directory="D:\Integration\state\MyProject1" />
    </project>

    <project name="MyProject2">
        <workingDirectory>D:\Integration\working\MyProject2</workingDirectory>
        <artifactDirectory>D:\Integration\artifacts\MyProject2</artifactDirectory>
        <state type="state" directory="D:\Integration\state\MyProject2" />
    </project>

</cruisecontrol>

Then, I won't have to specify these directories separately for each project. They will just get created under the project name under some default folder structure based on – i.e. D:\Integration\working\ being the base for

Best Answer

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>

Related Solutions

R – .NET automated build with cruisecontrol.net + nant – multiple assembly structure / best practice

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).

R – Targetting different Frameworks using MSBuild gives problems with dependencies

I've been revisiting this problem again, since I do not like to have to manually change the csproj file. (When I change my reference, I must not forget to adapt the csproj file again, to set the Private node to true again).

So, I've been digging into MSDN, and I stumbled upon this:

ResolveAssemblyReference.TargetFrameworkDirectories Property

Remarks This property is required to determine the CopyLocal status for resulting items.

If this property is not specified, no resulting items will be have a CopyLocal value of true unless they explicitly have a Private metadata value of true on their source item.

So, this means that there is yet another possibility, and that is to set the TargetFrameworkDirectories of the ResolveAssemblyReference task. However, is there anybody out there who knows how to do this ?
I've been trying different things, but nothing seems to be working ...

I've tried this:

<ItemGroup>
    <TargetFrameworkDir Include="$(SystemRoot)\Microsoft.NET\Framework\v2.0.50727" />
</ItemGroup>

<PropertyGroup>
   <TargetDirsToUse>@(TargetFrameworkDir)</TargetDirsToUse>
</PropertyGroup>

<ResolveAssemblyReference TargetFrameworkDirectories="$(TargetDirsToUse)" />

But to no avail ... Maybe someone else knows how to do this, or has a golden tip. (I've been spending way to much time on this f*cking issue).

Related Topic