Hi, thanks for posting!

This is the first time I've seen this issue reported, and the error message does appear most unhelpful. Are you making use of any build customisations or 3rd party frameworks that may interface with your build process?

Something that may be worth trying is to attempt to run the NCrunch build manually inside the workspace that NCrunch has built for your project. This will allow you to deductively troubleshoot the issue and find the difference that is causing the problem. Try the following:

1. Run NCrunch so that you see the build failure in the Tests Window
2. Right-click on the failed build, choose 'Advanced->Browse to workspace'
3. Open a command prompt at the location shown in the explorer window, and go to the directory containing the .vbproj file
4. Execute msbuild.exe against the project file in your command prompt.

You can find the msbuild.exe file under your framework install path (i.e. C:\Windows\Microsoft.NET\Framework\v4.0.30319)

It's also worth inspecting the workspace to make sure it contains all the files you would expect it to. The workspace is supposed to be identical in build functionality to your original project directory, the part that isn't identical is probably the cause of this problem.

What happens if you try running MSBuild.exe directly against the project as it exists in its original project directory? (i.e. outside the workspace). Do you receive the error when you do this?

Is this a project that you're able to share in any capacity? I can probably be of much more help if I'm able to try working with the source code.

Otherwise, try editing the .vbproj file inside the workspace, deductively removing parts of the XML (without causing different compilation errors if possible) until the compiler runs without an error. This may give us some clue as to why the compiler is behaving like this.

Are you making use of any assembly-level attributes as part of your project? To a key-file or so perhaps?

Something else to try... For all of the projects in your solution (use multi-select in the tree list if this makes things easier):

Turn OFF the 'Include static references in workspace' option
Turn OFF 'Instrument output assembly'
Turn ON the 'Copy referenced assemblies to workspace' option
Turn ON the 'Run post-build events' and 'Run pre-build events' options
Turn ON 'Allow static code contract checking'

.. Make sure you reset NCrunch after adjusting all these options. The goal of these adjustments is to make the NCrunch build operate as identically as possible to the normal VS build process, so if this does work you'll lose quite a bit of optimisation (but we'll then have more information to work from).

Does this make any difference?

In order for NCrunch to really work correctly (with all its features), 'Instrument output assembly' should be set to 'True'. NCrunch uses the instrumentation in order to perform code coverage analysis, so you'll notice that the coverage markers don't appear if you have it turned off throughout your solution.

If turning this setting off is making the error disappear for you, then likely it's related to one of the referenced projects of the one that is failing. Try toying with the setting for each of the project references until you can find which one is causing it - we can then try and narrow down to see what is special about this project that makes the VB compiler fail.

Nice work! Is there anything about this project that could be considered unusual compared with the others? For example, a different .NET framework version, perhaps some particularly low-level or structurally complex source code ...

It must be caused by a certain piece of code that the project surfaces and is referenced from the project that is failing. Is there any part of the project that is consumed by the failing project and appears to be structurally/syntactically complex? For example, a generic multidimensional array, or generic of generic, etc.