Hi Rob -

I just picked up this question while skimming through forum material, and realised that it hadn't been answered. I'm not sure how it slipped through my net, and I'm sorry it's taken so long to get back to you.

NCrunch uses a different security setup within its application domain to other test runners. I've yet to establish exactly why this setup is different or how to change it, though I have an item on my list to look into it in more detail. Thanks for making me aware of the problem.


Cheers,

Remco

Hi Oliver,

Right now NCrunch simply doesn't support working with partially trusted code (or code access security), as this adds a considerably complex dimension to its development and may not actually be possible with the way it works internally (more testing is required). I'd like to introduce an override to force it to deactivate security, although this is all still a work in progress and I can't yet promise when I'll have a fix available.

Meanwhile, I strongly suggest you switch off and avoid using code access security for code that is under test by NCrunch. The easiest way to do this is by using a compiler directive to turn off the CAS attributes when the projects are being built/processed by NCrunch. NCrunch sets a compiler conditional 'NCRUNCH' for specifically this purpose:

#if !NCRUNCH
[assembly: SecurityTransparent]
#endif

.. this should (in theory) solve the problem for your NCrunch test environment.


Cheers,

Remco

For anyone else that experiences the above issue, I've done a bit more digging to try and get to the core of why NCrunch is behaving differently to other test runners in this situation.

Because of the need to support pre-v4 versions of the .NET framework, NCrunch makes use of .NET framework 2.0 assemblies in some of the code it inserts for instrumentation. In v4 of the .NET framework, Microsoft introduced major changes to the security model that aren't seamlessly backwards compatible with the old CAS approach. This means that inside the NCrunch test environment, .NET v4 and above code may experience security related issues when attempting to impose constraints (or remove constraints!) using assembly-level attributes.

There is a useful article that goes through the motions of troubleshooting an identical issue encountered with Visual Studio MSTest's built-in code coverage.

Any solution to this issue from the side of NCrunch will require some re-engineering and looks like it will still be a long way out. If you encounter this problem, I recommend either using the compiler conditional shown above to deactivate the assembly-level security attributes for NCrunch builds, or to introduce the following attribute (perhaps with an NCrunch compiler conditional around it if you want to be certain of normal behaviour outside the NCrunch environment):

[assembly: SecurityRules(SecurityRuleSet.Level1)]

I hope someone finds this useful.


Cheers,

Remco

Hi Atreyu,

Thanks for posting!

The easiest way to handle this is to simply alter the VB project's .vbproj file and make use of NCrunch's conditional compilation. Inside the default/debug configuration property group, add the following line:

<DefineConstants Condition="$(NCRUNCH) == '1'">NCRUNCH</DefineConstants>

If you already have an existing 'DefineConstants' in the file, you may need to do something like this:

<DefineConstants Condition="$(NCRUNCH) == '1'">MYEXISTINGCONSTANT,NCRUNCH</DefineConstants>
<DefineConstants Condition="$(NCRUNCH) == ''">MYEXISTINGCONSTANT</DefineConstants>

I hope this does the trick.


Cheers,

Remco

Hi Dylan -

Can you confirm whether you're using the latest version of NCrunch? I vaguely remember there being a recent fix for several situations that can cause this issue..

Something else to look for - do you have any other security related attributes defined in the project you're experiencing this problem in?


Cheers,

Remco