I have a CSLA application that I'm trying to do WCF remoting with. In the DataPortalResult_Fetch method of WcfProxy.cs I'm getting this error message:
Could not load file or assembly 'msvcm80, Version=8.0.50727.1433, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
With a FusionLog as follows:
Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Perforce_WS\NextGen\main\Development\DotNet\G2\BusinessObjects\TestGUI\bin\Debug\TestGUI.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = ALPHA\dlabar
LOG: DisplayName = msvcm80, Version=8.0.50727.1433, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Perforce_WS/NextGen/main/Development/DotNet/G2/BusinessObjects/TestGUI/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : System.Runtime.Serialization, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file:
I get the same message running it using local host as I do trying to run it with the dataportal on a different machine. If I run it locally without any remoting, everything works fine. If I add the msvcm80.dll to the bin folder of the localhost folder, I get this compile error:
Error 203 A procedure imported by 'msvcm80, Version=8.0.50727.1433, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' could not be loaded.
At first I tried to do DotNet Remoting with the CSLA 2.1 framework, but I was getting the same message so I hoped that upgrading to 3.3 and switching to WCF would work, but it hasn't.
Does anyone have any suggestions?
Apparently that assembly is the C++ runtime (or part of it)? You must be using C++ or a component written in C++ within your DataPortal_Fetch method, or in an instance field of your object.
Given the serialization reference in the execption detail, I'd guess you have an instance field in one of your objects that either directly or indirectly references that C++ runtime.
I've never tried using C++ in .NET, so I don't know what quirks there might be - but I'm guessing you've found one...
Rocky,
Thanks for that suggestion, my object was referencing a dll that was referencing a dll, and so on, that was referencing ChilkatDotNet2.dll which is written in C++.
I'm in contact with the people at Chilkat but I'm afraid it really isn't their issue. Does anyone have any suggestions on how to overcome this issue?
The core issue is that you have a reference chain that is
causing an attempt to serialize one of their objects, and they hold a reference
to something in the C++ runtime, so you are trying to serialize some object in
there.
The solution is probably to avoid attempting to serialization
all those objects – break the chain somewhere in your code by marking an
instance field as [NonSerialized].
If you really need the value(s) that would no longer be
serialized then you may need to wrap those values in an object of your own
design that is not only [Serializable], but which also implements ISerializable
so you have control over what gets serialized – and thus can prevent the
serializer from trying to serialize the object from ChilkatDotNet2.dll.
Rocky
After removing some code from my DataPortal_Fetch method, I've been able to determine that the objects are deserializing on the server just fine because if I exit my DataPortal_Fetch before grabbing the connection string, I don't get any errors.
I'm utilizing the Encrypt Decrypt Functionality of the Chilkat dll to decrypt my connection string so if I don't call the Get Database Connection method, then I don't get an error because it doesn't have to load the Chilkat dll.
Therefore I believe my problem isn't with the remoting, but with how IIS is trying to call the Chilkat Dll.
Any different ideas given this new information?
After turning on Debugging on the Server (duh!) I'm getting a different exception. Amazingly, it looks like there is an inner exception that is causing the C++ module failed to load exception. I'm not sure what to do now...
InnerException: System.TypeInitializationException
Message="The type initializer for '<Module>' threw an exception."
Source="ChilkatDotNet2"
TypeName="<Module>"
StackTrace:
at <CrtImplementationDetails>.ThrowModuleLoadException(String , Exception ) at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) at .cctor()
InnerException: <CrtImplementationDetails>.ModuleLoadException
Message="The C++ module failed to load while attempting to initialize the default appdomain. "
Nested="A nested exception occurred after the primary exception that caused the C++ module to fail to load. "
Source="msvcm80"
StackTrace:
at <CrtImplementationDetails>.ThrowModuleLoadException(String errorMessage, Exception innerException) at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) at .cctor()
InnerException: System.Runtime.Serialization.SerializationException
Message="Type is not resolved for member 'CMS.G2.Security.G2Principal,CMS.G2.Security, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'."
Source="mscorlib"
StackTrace:
at System.AppDomain.get_Id() at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr function, Void* cookie) at <CrtImplementationDetails>.DefaultDomain.Initialize() at <CrtImplementationDetails>.LanguageSupport.InitializeDefaultAppDomain(LanguageSupport* ) at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* ) at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
InnerException:
I’m not sure what to recommend with that one. It appears
that the assembly doesn’t like being loaded within ASP.NET. Are you sure
their product supports web environments?
Rocky
I've have since given up on trying to get the Chilkat.Dll to work and used the .Net Cryptography to handling decrypting passwords. After removing all references to the Chilkat Dll it works perfectly fine now. Thanks for looking into this.
dlabar
Hi guys. Been a long time since I've posted here. I got this exact error and this thread was one of only two Google hits for the ModuleLoadException, so I thought I would share my thoughts.
I don't use CSLA.net, but I do use a very similar login / Principal strategy for web applications. So after four days of beating my head against the wall trying to track this down, putting assemblies in the GAC, recompiling my c++ with /clr, /clr: pure, trying to translate the c code to c# with an automatic translator (don't bother), modifying the PATH variable, and about a hundred other things that I don't remember now, I decided to bite the bullet and make my base IPrincipal object inherit from MarshalByRefObject. This was ok because I don't use remoting, I just hook up to remote databases and let TDS do the remoting for me.
Guess what? The entire error went away. Everything. It definitely has something to do with crossing AppDomain boundaries, and what I found out was that in trying to call into a c++ DLL, I was actually exposing an exception that was being swallowed by IIS. I don't know if it was coincidence, but my web apps seemed to speed up dramatically after the change, because there is no way to know for sure how many times IIS was throwing / catching / swallowing this exception.
The gist of this is that I would take a hard look at doing whatever it takes to make your base IPrincipal object inherit from MarshalByRefObject. Maybe have a context switch or a parameter that goes to a factory that creates a special one for web applications or something, since you rarely need remoting in a web context.
Here's hoping this post can save someone in the future from a lot of headaches and sleepless nights. Unlike dlabar, I had no choice but to get this working.
This is not something I’ve tried, so I have no idea,
sorry.
Certainly you could never use a remote data portal and expect to
have the principal flow to the server – that much is obvious.
Rocky
From: brucep
[mailto:cslanet@lhotka.net]
Sent: Tuesday, April 15, 2008 11:45 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Error on DataPortal with Loading assembly
msvcm80
Rocky, as a follow-on to this: my testing is going fine with
the IPrincipal class inheriting from MarshalByRefObject, but do you know
of any gotchas that I should be aware of?
Copyright (c) Marimer LLC