[edit: removed image link - problem description is still present in the 'steps to replicate' section]
Steps to replicate
------------------
1. In Visual Studio 2012, create a new Class Library project targeting .NET 2.0
2. Install NUnit via NuGet (Install-Package NUnit).
3. Insert the following code:
public class Example<T>
{
public Example() { }
}
[TestFixture]
public class ExampleTests
{
[Test]
public void ExampleTest()
{
var example = new Example<int>();
}
}
4. Note the following error:
System.InvalidProgramException : Common Language Runtime detected an invalid program.
Additional information
----------------------
Running VS2012 (Update 1) with NCrunch 1.42.0.12
The issue only appears when targeting .NET framework versions 2.0 and 3.5. Versoions 3.0, 4.0, and 4.5 do not have any issues.
The test passes when using the NUnit test runner, and the VS2012 NUnit test adapter.
Other info: 64bit Windows 7. NUnit v2.6.2. No NUnit dlls in the GAC. VS2010 also installed.
Any suggestions as to why this may be happening, or how to work around it?
This is a result of windows update KB2742616 which changes the behaviour of the JIT while processing .NET 2.0-3.5 assemblies. The change introduces a functional constraint that clashes with the way that NCrunch instruments for performance analysis.
You can work around the issue in one of the following ways:
1. Upgrade to NCrunch 1.44, which was released a few hours ago to specifically address this issue
2. Uninstall the windows update (may require system restore, and probably not the best idea unless it was installed very recently)
3. Update the project(s) in question to use .NET 4.0, which doesn't seem to be affected by this change
4. Turn off the 'Analyse line execution times' for ALL the projects in your solution
I am seeing this problem with a .NET 4 project that uses MSTest. NCrunch version is 1.45.0.12.
Turning off 'Analyse line execution times' solves the problem.
This is concerning. I hope there isn't a new update that also does this for .NET 4 ... is there a particular piece of code that seems to surface the problem for you? The .NET 3.5 issue described above was triggered by NCrunch instrumenting the constructors of generic types. Is there anything you can enable/disable in the codebase that allows you to reproduce the issue at will?