So, good news: I found and fix0r3d the code that broke NUnit.

As you may have guessed, NUnit wasn't broken. I was.

The code I thought I was working perfectly via debugger/VS.NET _WAS_ indeed working perfectly. I'd reflect over an assembly, instantiate a given type, invoke a method, and throw an exception PERFECTLY. Only I was reflecting and instantiating in my calling context (i.e. in my local AppDomain).

NUnit was barfing on me because the exception I was throwing was not correctly serializable. That's all.

How did I make it serializable Simple: decorate the exception with the [Serializable] attribute, and provide a default constructor that supports serialization. (NO THANKS to MSDN docs... they don't mention this in the SLIGHTEST.)

[Serializable]
public class BreakingException : Exception
{
	public BreakingException () : base() {}
         public BreakingException(SerializationInfo info, 
		StreamingContext context) : base(info,context) {}
}

Once I did that, all my problems went away, obviously. NUnit, and my remoting app, were then able to correctly handle serialization of my custom exceptions.

For those of you that haven't used nUnit yet, sorry. I broke it.

So I'm working on a cool new little pet project at home. And i wanted to set it up with a number of spiffy Unit Tests. I also wanted to make sure that exceptions are thrown when the component fires up and can't locate config info correctly.

So, I did something sick... I simulated an AppDomain firing up with incorrect config data. Creating the AppDomain is pretty easy. The trick came from trying to test instantiation of my component/type inside of that domain -- especially because my component is a 'static class' (private constructor with only static methods).

So here's what I did
1) Create the new AppDomain,
2) Remotely load an assembly into that domain (this assembly acts as a relay/proxy/scaffold in the remote domain, where I can further load assemblies and instantiate objects, and then pass references to those objects back to my executing (original) appDomain.
3) Once my scaffolding/proxy/relay is built... load a new assembly (of the type I want to test), instantiate an instance of the type I want to test (using Activator.CreateInstance (and set to use non-public constructors)), and pass a handle back to my calling appDomain.

The good news, it works PERFECTLY. I can step into it, watch the wheels churn, everything works 100% as desired. Makes me feel tough...

The bad news, nUnit chokes on it, and throws serialization errors. Just to make sure, I fired up the test itself (outside of nUnit) and stepped into it there  ... worked perfectly there as well. (i.e. fire up a console app, tell it to run my unit test.testxxxmethod() and everything works fine... nUnit just can't handle it.)

Must be something about how nUnit already creates proxies/etc. where it executes the tests to be run. (i.e. I'm probably opening a new appdomain from an app domain created by nUnit -- all that marshalling by ref is probably throwing it for a loop).

*sigh*