Project Atomicity

Description

When NCrunch prepares to build a project, it will first identify and copy all files relevant to the project into an isolated workspace for processing. The building of this workspace involves the complete extraction of a cloned project from its parent solution. There are many mechanisms in NCrunch designed to make this extraction as seamless as possible, although this design does have implications and imposes constraints on the structure of the projects being extracted.

Possible Problems

The extraction of a project from its parent solution requires the reliable identification of all files needed for the project to be built and tested in isolation. NCrunch works very hard to identify these files although there is the possibility that some may be referenced implicitly, causing build and test run-time issues.

To make use of separated projects in their workspaces, NCrunch uses its knowledge of the relationships between projects to artificially wire them together at build and test run-time. This means that if NCrunch is unaware of a dependency between projects, it is very possible that tests or builds may fail to run correctly.

An example of a possible failure scenario is a test that launches a webserver pointing at a website path relative to the test project assembly. This kind of reference is beyond just an implicit set of file references, as it also relies on the web project to first be built before the webserver is launched.

Solutions

Design Projects For Clean Separation

Although this may not be feasible for projects that have been developed for years without NCrunch, designing projects with separability in mind can save huge amounts of trouble when using NCrunch. Try to ensure projects clearly state their references to each other using <ProjectReference> tags in their .proj files. Avoid creating complex build situations that involve cross-references and reliance on implicit behaviour or solution structure. Avoid developing projects that introduce side-effects as part of their build process, or suppress custom build steps that do this by using conditional build behaviour.

Use NCrunch Reference Data To Find Referenced Assemblies

In the example cited above (a test launching a webserver), it is possible to make the test behave normally by using NCrunch's assembly reference data to find the location of the website root path. An example of this can be found in tests that build their own appdomains. The implicit project dependencies setting can also be useful in this situation if the web project itself is not explicitly referenced from the test project.

Use 'Additional Files To Include'

A very crude but simple solution is to treat all files and implicitly referenced projects used by a test project as extensions of the test project itself. You can use the Additional files to include configuration setting to include the files in the test project's workspace. In the webserver example cited above, this approach would mean that the website itself must be built manually using your IDE before the test code could work with the correct version of the website's assemblies.