Exception using CSLA in LinqPad

Exception using CSLA in LinqPad

Old forum URL: forums.lhotka.net/forums/t/9066.aspx

halcwb posted on Friday, June 11, 2010

Lately I am using LinqPad as a code prototyping and code testing tool. This works excellently, I reference a library I have written using CSLA 3.8 framework. Everything works fine, I can use the classes from that library just as I would use them in Visual Studio. I only run into a problem when I use authorization. This results in the exception as shown below:

System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Informedica.GenForm.Library.Security.GenFormPrincipal,Informedica.GenForm.Library, Version=, Culture=neutral, PublicKeyToken=null'.

   at LINQPad.ExecutionModel.Client.ExecutionComplete()
   at LINQPad.ExecutionModel.Server.StartClrQuery()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

RockfordLhotka replied on Friday, June 11, 2010

This is probably the same problem that occurs with unit testing.

In the unit test (nunit) case, the unit test tool creates a separate appdomain on which it runs each test. But the same thread is used across both appdomains. If you set a custom principal on the thread in the test, .NET serializes that object back to the original appdomain when the thread switches from the test appdomain to the original.

Of course nunit doesn't reference your business assembly, nor does your business assembly exist in the type loader path for nunit, so the object can't deserialize.

That sounds like your problem. So I bet LinqPad spins up another appdomain to run your code, but uses the same thread. So your code, running in the new appdomain, sets the principal. When the thread returns to the LinqPad appdomain, it tries to serialize the principal back, and fails because LinqPad doesn't reference your assemblies.

The unit test solution is to always make sure to clear the principal (reset it to something like a GenericPrincipal) before the test completes. I am not sure what you'll need to do in your situation.

halcwb replied on Friday, June 11, 2010

I was thinking in that general direction as well. I did add the references to my business library and the csla dll. The quick and dirty solution I use is to out comment all the code that uses the principal objects.

I will post this question to the LinqPad forum. If they have a solution I will post it.

Thanks -- Casper

Copyright (c) Marimer LLC