<CrtImplementationDetails>.ModuleLoadException thrown

ChrisM posted on Friday, August 07, 2009

I'm having an issue w/ the above exception on a command object I'm using in CSLA for Silverlight. I've read this thread:
http://forums.lhotka.net/forums/thread/21402.aspx

which seems to point at the C++ runtime and it's inability to use the custom CSLA Principal. My question: Is it possible instead to use the stand windows principal? I'm in an intranet deployment, and have access to the windows identity via IIS and the integrated authentication. Is there a reason NOT to use this, as from what I can tell it might solve my issues?

RockfordLhotka replied on Friday, August 07, 2009

You need to decide on your authentication and authorization strategy.

From a technical perspective you can use Windows auth, Membership auth or custom auth. CSLA .NET works with all of those options. Which option is right for you depends on your requirements.

By default CSLA .NET uses Windows auth - which is to say it doesn't do anything with the principal at all, and it is up to you to ensure that your environment is configured properly so the Windows principal is the current principal on the thread or HttpContext.

RockfordLhotka replied on Saturday, August 08, 2009

There's a project in the Test download - there are several test projects for
different authn models actually.

And this is covered in the CSLA .NET for Silverlight video series, along
with a sample app (http://store.lhotka.net).

ChrisM replied on Monday, August 10, 2009

Okay, this is what I can see so far. If I go the Silverlight path, I end up with a custom Principal on the client due to the fact that Silverlight can't natively get the local users security info. This custom principal then gets passed to the wcf portal along with any requests, which then fubars loading these c++ libraries that can't handle the custom Principal. So this is my solution: Modify the Csla.ApplicationContext class, adding a static IPrincipal called First. In the user get of Csla.ApplicationContext, if First is null set it to current. then in my command class, my data portal execute ends up looking like this:

protected new void DataPortal_Execute()
{
IPrincipal p = ApplicationContext.User;
ApplicationContext.User = ApplicationContext.First;
exec(); //do the actual command work
ApplicationContext.User = p;
}

This way the custom principal goes back to the client, but for this one call I use the native windows principal. Does this look like a good plan? It does work..I just don't want to fubar my Csla too much here.

RockfordLhotka replied on Monday, August 10, 2009