This post originated from an RSS feed registered with .NET Buzz by James Avery. Original Post: CallContext and NUnit Woes Feed Title: .Avery Blog Feed URL: /blog/Install/BlogNotConfiguredError.aspx Feed Description: .NET and everything nice Latest .NET Buzz Posts Latest .NET Buzz Posts by James Avery Latest Posts From .Avery Blog

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