An alternative that I've always liked is to use inner-classes to test your code, like this:

public class Foo
{
private void Bar()
{
// Do so work here in a private method
}

#region Unit Tests
#if UNIT_TESTS
[TestFixture] public class TestFoo
{
[Test] public void TestBar()
{
Foo foo = new Foo()
foo.Bar(); // inner class can call this method
}
}
#endif
#end region
}

You simply define UNIT_TESTS in Debug/Release builds if you want test code enabled, and leave it out from your Ship builds.

Also, you'll probably have a using statement wrapper,

#if UNIT_TESTS
using MbUnit.Framework;
#endif

As an added check, you can write a simple app that does reflection on all the types in the DLL to verify your ship build doesn't have any classes with test attributes. If no code references the test framework, your ship builds will automatically not load the referenced test framework DLLs, thus allowing you to ship your product like usual without pulling in test DLL dependencies (and associated bloat and licensing issues).