Hi Dan,

Thanks for sharing this issue. It may be difficult to recreate the mechanics involved here to get a clear picture of exactly how the build system is arriving in this situation, but I would guess that having an assembly version that changes on every build is probably causing some dependency issues inside the NCrunch workspaces. NCrunch's build system is probably reliant on an assembly being built with a consistent version number.

The only way I can think of to fix this would be to suppress your usage of the AssemblyVersionAttribute under NCrunch builds. Understanding that you can't remove this attribute in your normal build system, the solution would instead be to make it conditional on not being an NCrunch build. Under C#, this would be as simple as using the #!NCrunch directive to just block it out of the build. Unfortunately NCrunch doesn't have an equivalent to this under VB, so the simplest way may be to just remove your AssemblyInfo.vb file from NCrunch's build.

Inside your project XML, you'll see something like this:

<ItemGroup>
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

Try placing this inside an itemgroup with an NCrunch condition, as such:

<ItemGroup Condition="'$(NCrunch)' != '1'">
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

By doing this, NCrunch will ignore the AssemblyInfo.cs file and all of its contents. This means that the assembly version will be consistent for each build, and there won't be any version-specific referencing issues.

Hi Dan,

I may be able to offer a solution here that doesn't involve introducing hacks to your project files, but you probably won't like it.

To improve performance, NCrunch short-circuits your build system to only build projects that have changed. This is different from the standard VS/MSBuild approach where once a project has changed, ALL of the projects depending on it must also be rebuilt. The difference in performance is very significant on large projects. It can mean the difference between a 2-5 second wait before tests start executing vs a 30-60 second wait when working on projects deep in the solution structure.

When you use a wildcard to change the version of an assembly with every build, you've effectively broken this system, because the assemblies that are reliant on your changed assembly have their references fall out of date as soon as the assembly version is changed. These assemblies then need to be rebuilt.

If you like, you can turn off the above optimisation by changing your 'Copy referenced assemblies to workspace' setting to TRUE for all the projects in your solution. In theory, this should allow NCrunch to work with your solution without the project hacks being necessary, but I would expect this is probably not worth the cost of waiting for the build to run.

Hi Dan,

You're welcome to request such a feature on uservoice if you like.