In VS2010 my MSTest tests run just fine.
When running in VS2012 I am getting an error. The test sets the Csla.ApplicationContext.User with a Custom Business Principal. When EntityFramework is asked to provide a new ObjectContext I receive a SerializationException saying that my Custom Business Principal type cannot be found.
So far all tests that use EntityFramework fail when running through VS2012's test runner or Resharper7's test runner. I have tried NCrunch's test runner and they all pass.
Anyone else having issues like this? Any help would be much appreciated.
I think Microsoft did some major rework on the way mstest hosts and runs tests in VS12. My understanding is that these changes were necessary to support the ability they now have to host various test runners, not just mstest.
I haven't looked into this in depth, but the typical issue comes because the tests end up running on a thread that crosses AppDomain boundaries between the test runner and the actual test code.
The test code AppDomain has access to all your types, but the test runner AppDomain doesn't because it isn't hosting your code.
The solution is to ensure that the ApplicationContext.User property (System.Threading.Thread.CurrentPrincipal) is set to a neutral type before the test completes (before the thread leaves the AppDomain hosting your code and returns to the test runner AppDomain). A neutral type is like GenericPrincipal - something that is native to .NET itself.
Thanks Rocky! I'll take a look at this and let you know what I find out ...
Thanks Rocky, your feedback verified some assumptions and pushed us in the correct direction.
Ultimately our issue was that we use reflection to load our data access layer and thus EF is referenced there and does not know about the custom principle. It is interesting that EF cares about the principal. Our immediate solution was to wrap the call to the ObjectContextManager and manage the setting and resetting of the principal. Thank you for your help and nudge, it gave us a few things to try that led to our ultimate issue.
On an associated tangent, do you think an IoC container would have alleviated the issue of not knowing about our custom principal?
I think I've got to the bottom of this now. The problem that Rockford is talking about was something that manifested itself prior to 2012 in my experience - this is something all together different!
I think that the key behavioural difference between the 2010 and 2012 test runners is that the 2010 runner causes the ConfigurationManager class to be fully initialized prior to running the test.
When ConfigurationManager is initialized it reads from AppDomain.Evidence, which causes a stack walk - if you have placed a custom principal on the thread this ends up being de-serialized in the original AppDomain, which fails with the SerializationException you're seeing.
The fix is a little dirty, but if you make a call to ConfigurationManager.GetSection("ANY DUMMY TEXT") prior to your test then things should start working again.
FWIW, we have a base class that all our unit test classes derive from - putting this call in the constructor of that base class works fine.
HTH,
Mike
Copyright (c) Marimer LLC