Hi Alan! It's great to hear from you and I hope that all is well.

I've had a go at running NCrunch against Cavity, and I think that you may have some work ahead of you to make NCrunch work correctly against a solution of this structure.

NCrunch works by extracting individual projects from their solution, isolating them in another area of your hard drive, then building and testing them in this isolated environment. In order to properly isolate a project, NCrunch needs full control over the way in which the project references other projects and DLLs. This control is exerted over the project by manipulating the .proj file at an XML level inside the NCrunch workspace, replacing the <Reference> and <ProjectReference> tags with <Reference> tags to the specific assemblies required to build the project. This creates problems when working with Cavity, as Cavity stores its shared assembly references in the 'Any.references' and 'Web.references' files - which cannot be manipulated by NCrunch. The result is that NCrunch is throwing exceptions while preparing Cavity's .proj files for build.

After moving the shared references out of the MSBuild imports, NCrunch worked correctly for me against the Cavity.Web solution. I assume that the other solutions could be fixed the same way.

If you need to get more error information out of NCrunch, the best place to look is the processing queue. If you set your 'Logging verbosity' to 'Detailed' under your NCrunch Global configuration, the queue will show you detailed error/trace information directly from the MSBuild output.

Something you may find useful is that NCrunch sets an environment variable $(NCrunch) == '1' in its build environment, which you can use to implement custom build paths/logic.

I'd really like to learn more about why the bug report tool failed for you. Others have also complained of this, and I'm hoping to try and rule out any connectivity issues. If you still have me on skype, maybe ping be sometime when you're free as I'd really like to run some connectivity tests. There's not much worse (or more ironic) than a bug in a bug reporter ...


Cheers,

Remco

The tricky thing with solving this inside NCrunch is that doing so would require NCrunch to have a logical understanding of the entire workings of the build scripts being included by the <Import> tags in the proj file. In the case of Cavity, a very rudimentary understanding would be ok (as the scripts do not contain dynamically derived References), though you can imagine the complication if someone were to have a build script with logic where the reference to a particular assembly was calculated using an MSBuild task non-deterministically.

The general goal behind NCrunch's workspacing has been to make it as configuration-less as possible, though for situations where people have heavily customised/hand-scripted build environments, providing meaningful error information is often the only feasible alternative. In this particular situation, the error was obscure and did not give any indication on what was causing the problem or how to resolve it. That is definitely something I need to address.