nunit on release build: “Common Language Runtime d

问题:

I upgraded our software from vs2008/.net 3.5 to vs2010/.net 4.0. All third party libraries (most relevant: nhibernate 2.1.2 or 3.0.0, nunit 2.5.2) are still compiled using vs2008. When I run the unit tests for the debug build of our software, everything works fine. On the release build, nunit reports exceptions on 33 of 228 tests: System.InvalidProgramException : Common Language Runtime detected an invalid program. It always happens on the same tests, for both nunit-console and the Resharper 5.0 test runner. When I run them using the Resharper "debug unit-tests" command, all tests pass. It makes no difference whether I run the tests individually or batched. The exception always happens near nhibernate query calls, but I can't say for sure since the release build stack trace is somewhat sparse. It does not depend on the nhibernate bytecode generator, the same exception appears for castle and linfu. Does anyone have an idea how to debug this?

Edit: Removing Spring.NET had no effect on this issue.

Edit: When I switch the release config debug output to full instead of pdb only and deactivate the optimize code checkbox, the exception disappears. Both settings are required, if I change only one of them the bug remains. However, a different set of tests fail if I only change one. All class libraries are compiled for Any CPU.

回答1:

This is probably a stupid question: are you sure all of the assemblies are compiled to the same architecture (x86/x64)? I ran into this once a while back.

回答2:

I had something similar when i selected "NET Framework 4.0 Client Profile". Try to change the target framework to "NET Framework 4.0"

回答3:

My application would also run in debug but crash with that same exception on release configuration. The cause was that I had a method with the conditional "DEBUG" attribute, which returned a value...

Of course, in release config, all methods with the conditional "DEBUG" attribute are changed into stubs with no return value. So the IDE might think your types are fine gong by the code analysis and offer no warning, but the compiled application has return type miss-matches!

Just thought I'd add this for those banging their heads against a wall with this issue.