At my current client we are using the CallContext to store an object to be used from both sides of a remoting boundary. Basically how this works is that you create an object, add the ILogicalThreadAffinative interface, and then stuff the object in the CallContext object. If you want to learn more about it: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimeremotingmessagingcallcontextclasstopic.asp
So, everything is great... until you try to test something with NUnit that uses the call context. I ran into this issue when testing some code using TestDriven.NET. When I tested a method that used the CallContext I would get an exception that my assembly could not be loaded. This didn't make alot of sense until I talked to Jamie Cansdale, the author of TestDriven.NET, and he explained what was going on. He pointed me to this post that is pretty much the exact same issue.
So to fix this issue you put your assembly somewhere where NUnit or TestDriven.NET can find it. This means either in the respective applications directory or in the global assembly cache, neither of which is a great solution. If your assembly is frequently updated this really leaves you with a couple options:
1) Setup a post build event to copy your assembly to NUnit or TestDriven.NET's directory. (Pretty Ghetto)
2) Create a TextFixture Setup method that add your assembly to the GAC and a TextFixture Teardown method that removes it from the GAC. (Semi Ghetto)
Jamie is going to try and look for a better solution, hopefully he will find something.
Anyone else find a better solution?
-James
Maybe by putting your code on one side of an Interface and, when you run your unit tests, put in some stub code to implement the interface?
Maybe if it was possible to set the BaseDirectory property of the AppDomain that nUnit creates... (instead of using nUnit's home directory it could be configured to be the bin folder where your assemblies lived)
That is what I suggested to Jamie. Perhaps have an assembly folders configuration option in NUnit where you could specify the folders where your assembly lives.
I am not sure if this is the route he will take or not though.
-James
Assembly locking would be the problem. You don't want to load user assemblies into the default test runner app domain.
The trick will be to completely isolate the test runner thread in the test domain. This will involve a message pump to avoid making any callbacks on that thread.
It could probably do the same thing it does with assemblies now. NUnit loads assemblies and does not lock them, not anymore anyway. Your solution sounds like it would not need any user configuration which would definitly be ideal.
-James
Try marking your assembly (from AssemblyInfo.cs) with the "AllowPartiallyTrustedCallers" attribute.