Vibrant discussion about CSLA .NET and using the framework to build great business applications.
sounds reasonable to me. Unfortunatly, I don't think VSTO offers
anything so clear. The work around could be to check that the assembly
resolve event is handled each time your code runs.. perhaps not nice, but it
I was having exactly the same problem with VSTO 2.0. Resetting the Principal to be a GenericPrincipal works. In the form's Close event I'd reset the Principal to be GenericPrincipal, and right after the ShowDialog call, set it back to CSLA principal.
I discovered a better solution though. Just drop a BackgroundWorker control on your form while in design mode. You don't necessarily need to do anything with it, just having it, makes the serialization exception go away.
I don't know why this takes care of the issue, if you do, please share.
I've just encountered this problem in a Word VSTO using .NET 4.5.1 and CSLA 4.5.501
The serialization workaround made no difference to me, but luckily I have come across this post by MikeGoatly:
This solved my issue - I had to force the ConfigurationManager to reinitialize BEFORE I set my Principal on the thread. Not entirely sure why but it works! If I don't call the ConfigurationManger to force it, I get a Serialization Exception regarding my custom Principal class.