Project Build Issues

While NCrunch has been designed very much with compatibility in mind, MSBuild is a flexible beast not often kept in its cage. If you've hit a situation where NCrunch thinks your build is failing when it shouldn't be, then most likely you have a build compatibility issue. Not to worry - build issues are usually easy to solve.

Implicit Build Dependencies

By far the most common reason for builds failing incorrectly lies in files that the build depends on implicitly. Generally, an MSBuild .proj file will articulate every file dependency related to the build - ranging from source files to project references, .snk key files, etc. If you are using a custom build step or target of some kind that somehow makes use of a relative reference to a file that isn't listed in the project file, then NCrunch won't know about the file when it sets up the workspace in preparation for a build.

This is usually easy to spot, as you'll often see a build error complaining about a missing file. Sometimes the errors can get more ambiguous - particularly when including custom scripts into your build using the MSBuild Import tag.

There are multiple solutions to this problem.

When you are uncertain of whether files are being left out of an NCrunch workspace, a useful trick is to inspect the workspace to check for missing files. To do this, right click on the failed build inside the Tests Window, then choose Advanced->Browse to workspace last built for selected project. This will open an explorer window pointing at the project inside its NCrunch workspace, allowing you to compare the contents of the workspace with the normal project directory.

To help with further diagnosis, you can also try a command-line MSBuild invocation against the project file in the above workspace. If the build passes in this situation, you can be certain that your build problem is not caused by NCrunch's workspacing and is likely to be the result of a different issue.

Assembly Collocation Assumptions

As part of its default build behaviour, NCrunch will avoid copying assemblies referenced by a project into its output directory. This approach can have implications for project builds that make use of frameworks relying on assemblies being collocated.

A quick way to identify whether this is the cause of your problem is to enable the Copy referenced assemblies to workspace configuration option for the failing project and its dependencies.

Pre/Post Build Events

By default, NCrunch will disable all pre and post build events as configurable within your IDE. Most of these events are used for workarounds while generally operating in a development environment, and they simply don't apply to a normal build process.

In situations where this isn't the case, it's possible to easily enable these events using NCrunch configuration. Note that pre/post build events often make use of implicit dependencies, so make sure to watch out for this. Also beware of using any events that may significantly slow down the build process, as this will impact your engine cycle feedback times.

Never Ending (Repeating) Builds

NCrunch's build process is triggered by changes that are made to the foreground solution that is open in your IDE. As the change tracking extends to solution files on disk that are not open in the IDE, it is possible for situations to exist that trigger NCrunch to continuously build projects in an endless loop.

These situations are caused by user code within an NCrunch workspace reaching out of the isolated workspace and changing files that exist in the foreground solution. Usually this happens as the result of absolute file path references within your codebase.

NCrunch's behaviour relies on projects being extractable and atomic, and therefore it cannot work with code that relies on absolute file path references.

There are several ways to easily track and identify absolute file path references that can cause this problem:

• Change the location of the foreground solution - Close your IDE, move your solution to a different area of the hard disk, then re-open the solution and try building and running tests with your usual test runner. If the code contains absolute file path references, there is a good chance that it will fail to find the file it is expecting and blow up with an exception, giving you a vital clue as to the location of the absolute file path reference.
• Global search - Try taking a part of the directory path to your foreground solution and conducting a case-insensitive text search on your codebase.
• Read only files - Try setting your entire solution directory (and everything in it) to be read-only using file attributes. A more extreme approach could be to apply read-only access to the files via Windows security. When builds and tests are then run, there is a very good chance they will explode with an exception giving a clue as to the location of the absolute file path reference.

Signing Issues/"Strong name validation failed"

Because NCrunch manipulates the assemblies that are output from the build process, it needs to re-sign anything it touches. If you are experiencing signing related issues while attempting to build or run tests, it's possible that you're using a more complex signing approach than NCrunch was designed to handle (for example, you may be using a partial key or password protected key file).

NCrunch has a project level configuration option, Prevent signing of output assembly, that if set to true will suppress signing of an output assembly and should allow you to work around these issues. Note that If you set this configuration option to true for one project, you may also need to do this for all the projects in your solution to keep the signing approach consistent.

Problems with MS Test Private Method Accessors (i.e. "Microsoft.TeamTest.targets" errors)

MS Test private accessors require assemblies to be adjacent to each other in order to work correctly. This is a serious constraint for NCrunch, which normally keeps built assemblies separated and wires them together as needed.

NCrunch will usually detect when private method accessors are being used, but there have been situations reported where this detection fails and the 'Microsoft.TeamTest.targets' error is raised.

If you experience this problem, try turning on the Copy referenced assemblies to workspace setting for ALL relevant projects in your solution. You will likely notice a large increase in build times but this should allow NCrunch to process your solution without further issues from the accessors.

Paths Too Long

If you receive build errors related to file paths being too long, try adjusting your Workspace base path configuration option to make NCrunch deposit its workspaces closer to the root of your hard drive.

"Project requires Code Contracts"

The userdoc.pdf for Microsoft Code Contracts recommends placing an additional step into your project file that will throw a build error if Code Contracts is ever disabled. While the purpose behind this build step is obviously well intended, the step does not play well with NCrunch as NCrunch can disable Code Contracts during its build process.

If you ever see this error message, the recommended solution is to either remove the build step or to make it conditional on the $(NCrunch) environment variable. You can also turn on Code Contract checking in your NCrunch configuration, though this may have an impact on your build times.

'ReflectionOnlyAssemblyResolve handlers must return Assemblies loaded for reflection only'

This build error is caused by a problematic build property that exists within the project NCrunch is trying to build:

<AlwaysCompileMarkupFilesInSeparateDomain>false</AlwaysCompileMarkupFilesInSeparateDomain>

Setting this property to true will allow NCrunch to properly build the project (while also allowing the project to function normally for command-line builds). It has been reported that Microsoft Blend 3 templates often have this property included in the project file, for reasons unknown.

Custom Builds

If you are running a customised build process or making use of frameworks that are not required in the NCrunch workspace, it may be worth selectively changing build properties or disabling parts of your build. NCrunch contains overrides that allow you to do this.

Compatibility Mode

If you are experiencing issues with building or running tests within projects and you cannot identify the cause of the problem, it may be worth switching on compatibility mode to help you narrow down the problem.

Ignoring Troublesome Projects

If you are experiencing serious problems with building a project without any solution possible, you can also completely ignore the project using NCrunch configuration.

Be aware that ignoring a project will cause builds for projects depending on it to fail.