< Part One: Medium Trust primer

> Part Three: Download the code

Welcome to Part Two, wherein we will tackle the beast that is Medium Trust in our NUnit tests. If you just want a downloadable zip to get going, you can always jump to part three.

Based on what we learnt in the previous post around how the permissions are stored in configuration, a simple option is open to us. The basic premise is that in our unit test, we’re going to spin up an AppDomain and pass in the same permissions from configuration that the ASP.Net hosting engine uses. We’re then going to run the test method in that partially-trusted AppDomain, rather than in the full-trust AppDomain of the test runner.

Simples! The end. Bai!

Well, not quite. First, some gotchas.

Spinning up another AppDomain is called “sandboxing” for a reason: they are totally separate, and any communication between AppDomains has to be done via .NET Remoting using serializable objects, just like using your own Remoting channel, WCF or a good ol’ SOAP web service on another machine. Can you spot the first gotcha yet?

Gotcha 1: You can’t just use AppDomain.SetData to pass objects by value from your test to a Medium-Trust domain because it doesn’t have permissions to deserialize them fully.

Makes sense when I put it like that, but it took me an hour of wasted time before I facepalmed and almost quit coding forever.

There aren’t ways around this. Passing an object to another AppDomain, whether it’s via the SetData and GetData methods, requires the object to either be serializable (if you want to pass it by value) or inherit from MarshalByRefObject so that you can deal with the object as a regular Remoting proxy to the other AppDomain.

Part of the point of spinning up the other AppDomain is precisely to prevent certain code from running, you know, like serialization that can get/set private members.

Yeah, I wasn’t proud. A whole hour.

So the next idea was to use the power of MarshalByRefObject to instantiate something in the partially-trusted AppDomain, and control it from the original fully-trusted AppDomain of the test runner. This is pretty much how we’ll solve the problem, but wait:

Gotcha 2: It’s tempting, but we can’t just make our entire test fixture inherit from MarshalByRefObject.

Let’s agree that it would be a complete pain in the arse to have to replicate the nice, established features of a test runner. Agreed? OK, with that sorted: we can’t have our test fixture inherit from MarshalByRefObject to solve this problem.

We need the partially-trusted AppDomain to “own” the instance of the test, and run it there. If we’re going to try to use an existing test runner (NUnit’s, ReSharper’s, TeamCity’s, etc.) then our first point of entry into a test is when the fixture is already running.

The solution workflow

The concept I’ve arrived at is, as always once you’ve spent ages banging your head against a wall, quite simple in hindsight.

Here’s how the workflow will happen – again, this is just within a standard test runner:

  • During fixture setup:
    • Our fixture will get set up by running code marked with the [FixtureSetUp] attribute
    • We’ll then create the partially-trusted AppDomain
    • We’ll tell that AppDomain to create a new instance of a simple marshalling class that can run a method for us when given a MethodInfo class. By calling AppDomain.CreateInstanceAndUnwrap(..), we’ll get back a Remoting proxy to that object so that we can control it from our original test runner.
    • These will both live as fields on the test fixture that we can access from each test.
  • Before each test:
    • Out test setup code, still running in the full-trust AppDomain, will get run because it’s marked with the NUnit [SetUp] attribute
    • At this point, we’ll get the name of the current test from NUnit’s TestContext, and tell our simple marshalling class to do two things over in that partial trust AppDomain:
      • Run a TestSetup method, to make sure if it has “real” setup work to do, that’s still fine
      • Run the actual method. We get that by using Reflection in our full-trust AppDomain to grab the MethodInfo of the current test name from NUnit’s context.
    • Our marshaller will then run the exact test method in the partial trust domain.
    • If the test fails, we can figure out why, and if it’s to do with permissions, BAM our time has been officially saved

“But wait!” I hear someone wail at the back, “By running the test in the SetUp part, you’re now going to run the test again in Full Trust!”

Well, I thought of that.

NUnit has a funny thing called a SuccessException. It’s how it guarantees that if you call Assert.Pass() in your test, the rest of the test will likely not execute – pretty much what you’d expect.

So, in our “management” set-up code, we’re going to intentionally throw a SuccessException. I took a look at the NUnit codebase to clarify, and sure enough that prevents the test from executing a second time.

The code, where’s the code?

Well, I thought I would just give you theory. Kidding! I’m hilarious. The downloadable code is on the next post – I really need to make my blog more developer-friendly, so for now it’s a fresh new page for us.