I have set up Code contracts for projects in my solution and NCrunch fails to build some of them with error described in this topic: http://forum.ncrunch.net/yaf_postst487_ccrewrite--0--0--Rewrite-aborted-due-to-metadata-errors--Check-output-window.aspx
I have tried to build project with MSBuild in NCrunch's workspace and it build fine with no errors.
I use v2.7.
How can I find out what goes wrong with those projects?
Andrii
EDIT: I have tried to unload files from projects one-by-one and comment-out lines of code and I was able to find exact lines caused build to fail with the error, but I have completely no idea why builds fail. I couldn't find any relations or patterns.
The first thing that jumps into my head is that NCrunch's instrumentation may be creating an IL arrangement that Code Contracts is unable to process.
Most of the testing of NCrunch's instrumentation has naturally been performed directly using the JIT, which uses a different interpreter to Code Contracts. This means it is possible for code to work for one but not the other.
If you're able to share with me a piece of code that can consistently reproduce the problem, I may be able to get it fixed. Otherwise I think the best option may be to try using code coverage suppression comments around the code in question. This will disable instrumentation for the block of code, likely allowing Code Contracts to work. If this doesn't fix things, does disabling the 'Instrument Output Assembly' project-level configuration setting for the project make any difference?
I have tried to use comments and set Instrument Output Assembly with no effect.
Two of three projects that fail don't use CodeContract yet. And third fails in the part that don't use CodeContract either.
The code in question is below. If pass null instead of email.ValidationUrl assembly build fails. Second class resides in different assembly.
I've tried to rename/add new property to ForgotPasswordEmail class and build always fails when there is a property access. Two other assemblies has other reasons to fail.
Thanks for sharing the sample project. I don't think there's any way I could have properly analysed this problem without it.
Deeply buried in the MSBuild output was the following:
ccrewrite : error : Rewrite aborted due to metadata errors. Check output window
Assembly reference not resolved: System.Web.Mvc, Version=5.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
Could not resolve type reference: [System.Web.Mvc]System.Web.Mvc.UrlHelper.
elapsed time: 1765.7232ms
C:\Program Files (x86)\Microsoft\Contracts\MsBuild\v12.0\Microsoft.CodeContracts.targets(254,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite.exe" exited with code -1.
It seems that ccrewrite is failing because of an assembly reference error. The System.Web.Mvc DLL isn't used by the project being built, but it is an indirect dependency via another project referenced using a projectreference. ccrewrite is relying on indirect references being co-located with referenced assemblies - something that NCrunch won't do by default because this prevents it from optimising your build.
To make this work, you will need to turn on the 'Copy referenced assemblies to workspace' NCrunch project-level configuration setting for projects that are being referenced by the project ccrewrite is operating on. In your sample solution, turning this setting on for the Emails project solved the build problem.
This probably would have been much easier to solve if Code Contracts were reporting its error information correctly. Unfortunately it seems to have output the critical piece of information as a simple build message, thus excluding it from the visible failure message.
Thanks again for supplying the sample solution. This really made life much easier.
If you set the 'Log Verbosity' global configuration option to 'Detailed', NCrunch will allow you to inspect the detailed MSBuild output inside the processing queue. Simply find the project that has failed to build inside the queue, and you should see a full dump of the build output below it.
I'd definitely recommend setting the 'Copy referenced assemblies to workspace' on for ALL the projects in your solution. You can then selectively disable them one at a time to see which ones actually require it. Unfortunately this setting will have quite an impact on your build times, so it's better to avoid it if at all possible.