Any docs for NCrunch's AppDomain setup? (Ref running tests in Medium Trust from BoxBinary.com)

I recently implemented a method for running tests in a Medium Trust context (part three here (- BROKEN LINK -))

It's working great for us in R#, NUnit and TeamCity's runners.

This involves setting up a new AppDomain loading the PermissionSet from the web_mediumtrust.config, and invoking the test method in the other AppDomain. It's not feature-complete (I don't attempt compatibility yet with passing in parameterised tests) but for parameterless tests it works great.

I'm having a prob with NCrunch though, in that I'm unsure how to determine the assembly resolving policy of NCrunch and my partial-trust AppDomain cannot resolve referenced assemblies because the AppDomain.CurrentDomain.BaseDirectory of the NCrunch runner's domain only contains the dll of the actual test project (as would be expected).

I can turn on "copy all referenced assemblies to workspace" in the NCrunch settings, but this has all the usual downsides, and it would be far better instead to know what NCrunch is doing already to resolve referenced assemblies so I can detect and take advantage of the same logic. Providing, of course, that logic works in partial trust :)

I'll be blogging about NCrunch in the near future, and would be the icing on the cake to reference back to my Medium Trust posts and say this works there too.

BTW, if you want to collaborate on getting NCrunch to support running tests in Medium Trust, please do let me know.

Cross appdomain/process tests do generally tend to suffer from the fact that NCrunch artificially wires together its test domains from files that can exist in separate locations.

There is some documentation in the wiki that briefly describes how you can set up your own appdomain by using references to assemblies already loaded into the NCrunch test appdomain. You can rely on NCrunch to have loaded all required references into your appdomain before any tests are run.

In terms of running tests with medium trust, this isn't really an area that's been well tested with NCrunch (to my knowledge), though in theory sandboxing your own application domain would allow you to do this. An unfortunate side-effect is that you won't have any code coverage from NCrunch for code that is executing inside your own application domain or process, as it doesn't have control over how this domain is managed.

I admit that I haven't come across any situations before where people had a need to do something like this, so I'm guessing it's to test some kind of application specific functionality that needs to make use of .NET security features. Is the scope for this kind of test very large for you?

Going off the feedback I've got for the post series so far, it's not an area that's well exercised full stop really. I devised the solution to avoid us having extension methods / library usages creep into our codebase that unwittingly don't support Medium Trust (e.g., the Clone() method I use as an example in the post series was taken from perhaps the most simple yet major stumbling block in getting Fluent NHibernate to work in Medium Trust when using SubclassMaps)

Our Framework needs testable support for Medium Trust (at least, the default configuration of it) for users using our Framework on shared hosting, so that it's not a case of us writing & running integration tests of the UI simply to assert compatibility otherwise we'd have to have massive code coverage in our integration tests which is just not feasible with our current resource levels (OSS, free & MIT)

I'll take a look at grabbing the assembly references from the existing NCrunch AppDomain, although sadly I think that's not going to be practical due to the restrictions in the secondary domain - but I'll let you know how I get on.

Cheers
Alex

Thanks, I'd like to hear how you get on with this. I've made a note to have a deeper look into making this possible with NCrunch, though it's hard to make any commitments on whether I'll be able to do so at this point in time :)

Cheers,

Remco