1
votes

I am in the process of configuring my company's build server (running CruiseControl.NET) to run NUnit tests. To improve build time by reducing file IO, the build is setup to turn Copy Local off using a custom target file (basically what is shown here: How do I override CopyLocal (Private) setting for references in .NET from MSBUILD). However, Copy Local = false brings up runtime assembly binding errors ("could not load file or assembly") when running NUnit on the build server for test projects that reference other assemblies, because those assemblies are not copied into the /bin directory of the test project.

I can turn Copy Local on to get this to work, but that slows down the build. I am wondering, is there a strategy I could be using to be able to run NUnit tests on the build server while keeping Copy Local = false? I assume this situation has applied to someone else before and I'm missing something obvious.

For reference, here is how I am running each test project in the CruiseControl.NET build config:

<exec>
     <executable>nunit-console.exe</executable>
     <baseDirectory>C:\Program Files\NUnit 2.6\bin</baseDirectory>     
     <buildArgs>C:\Source\UnitTests.csproj /xml:C:\BuildLogs;\$(ProjectName)\NUnitResults\nunit-results.xml</buildArgs>
</exec> 
1
Does the file copy really take that much extra time? Sounds like you might need a better build box, or perhaps split the build into several smaller builds that handle separate modules.Pedro
@Pedro Unfortunately I don't have any numbers for comparison, but I was told it was a "significant" increase in build time (and this matches what I've eyeballed). You are probably right that this comes down to the build box (particularly the disk) being the bottleneck. If there's nothing strange about my setup then this gives me ammo to get a better build server :)Bobby Everyteen

1 Answers

3
votes

At runtime e.g., during test execution you need to locate the referenced assemblies somehow. I can't think of an easy way to avoid a final copy to the test project's output directory and I don't believe that this final copy action slows your build process down significantly.

In case you have a huge solution with lots of projects and many dependencies copying around the assemblies could be an issue.

Example:

Let's assume you have 26 projects named A to Z in your solution with A depends on nothing, B depends on A, C depends on B... you get the idea. Z is you test project. As I said: I can't think of a way to avoid having A.dll to Y.dll in the output directory of Z during test execution.

If you keep standard project configuration A is compiled to A.dll and copied to [SolutionDir]\A\bin\[Configuration]\. Then B is compiled to B.dll and copied together with A.dll to [SolutionDir]\B\bin\[Configuration]\. Then C is compiled to C.dll and copied together with A.dll and B.dll to [SolutionDir]\C\bin\[Configuration]\. This way A.dll is copied 26 times, B.dll is copied 25 times, and so on.

In this case my advice would be to let the output directories of all projects point to a single solution output directory e.g. [SolutionDir]\bin. That's what turbo-boosted our build process.