.NET Runtime version 2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506) Error in Event Log
I am getting this error in the event log calling a 3rd party classlibrary
.NET Runtime version 2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506)
The code is C# build with Borland Developer Studio 2005/2006 complied against v1.1 Framework this error occurs whenworkstationhas v1.1. and v2.0 of the frameworkinstalled.
Our classlibrary has config file which specifies v1.1 as the supported runtime:
<supportedRuntime version="v1.1.4322" />
<publisherPolicy apply="yes" />
<probing privatePath="" />
<gcConcurrent enabled="true" />
It is calling a 3rd party class library written in VB.NET which will returns and array of objects
The code, is using the reflection API since the 3rd party can any version.
Type oPolicyType = oConneXionClassLib.GetType("ConneXion.Policy", true, true);
object oPolicy = oConneXionClassLib.CreateInstance(oPolicyType.ToString(), true);
FieldInfo oTAMUserName = oPolicyType.GetField("TAMUserName");
FieldInfo oTAMPassword = oPolicyType.GetField("TAMPassword");
FieldInfo oLicenseKey = oPolicyType.GetField("LicenseKey");
FieldInfo oClientID = oPolicyType.GetField("ClientID");
MethodInfo oFindPolicies = oConneXionType.GetMethod("FindPoliciesForCustomer");object oParameters = new object;
oParameters = oPolicy;
oParameters =Array.CreateInstance(oPolicy.GetType(),10); object oConneXionResult = oFindPolicies.Invoke(oConneXion, oParameters); //Fails when invoking
oSuccess = (Boolean) oConneXionResult.GetType().GetField("Success").GetValue(oConneXionResult);
I am unable to recreate the error in our development environment but is happening @ client.
Any help with this is great appreaciated!!
Is this an ASP.NET application or other app that is running under IIS?
If so... from the sounds if it... you are running your 1.1 built application under the 2.0 Framework (which the version in the error message confirms) in IIS... something that is not configured with the supportedRuntime value in the .config file but instead an IIS level setting which can be changed at the application level with Denis Bauer’s ASP.NET Version Switcher.
Otherwise you might take a look at the MSDN KB article which talks about this issue (although the circumstances seem a little different) and perhaps try the suggested fix.
If this app is not doing anything with IIS... Hum.
It’s also worth noting that when supportedRuntime is set... it is not used for just a library but instead for the entire application... so the setting in MyLib.dll.config is worthless while it in MyApp.exe.config (where your apps filename is MyApp.exe) sets the runtime that will be used, even when MyApp.exe isn’t a .NET application.
Well... there goes the first idea of changing the runtime in IIS... My earlier comments on your library being run in the 2.0 CLR rather than the 1.1 still stand though.
The .config file where you specify the supportedRuntime property... make sure that its name is based on the name of the application that is using the COM component (ie if from MyApp.exe, config file would be MyApp.exe.config).
Thanks for the info Brendan, but
The classlibrary is invoked from Win32 application why would the config file need to be in the name of the application?? CLR would only be loading ClassLib, correct??
Also why is the code failing when call 3rd party why not before??
Win32 Application -----COM------->.NET 1.1 Classlib ------invokes-----> 3rd party .NET Classlib-----???---->3rd Party Application
The reason for needing the config file to be named for the exe and not the dll is because of where the CLR is hosted/loaded.
Remember that any application that uses the CLR such as a .NET app which uses it right off the bat or an unmanaged one that calls managed code has CLR is hosted within that applications memory space and when the configuration data for the CLR is loaded and applied, it is done within the scope of the application and thus the need for the config file to be named for it.
Another way to think about this is that if you could specify the runtime for each dll individually, it would theoretically be possible to have a single application host multiple CLR runtimes... something that thankfully isn’t possible due to the great potential for break downs.
Instead, it’s all one version or another and while 2.0 can use assemblies that were compiled for 1.0, 1.1 and 2.0... it isn’t always able to do it as well as the versions they were compiled for and this is why when a .NET application (or assembly) starts up, it asks to be loaded in the CLR version it was compiled for (or what is specified in the appropriate config file) and if it is unavailable and no rules prohibit it, will be loaded into a higher version.
My guess is that the reason this hasn’t failed before is that the machines you’ve run it on in past had the 1.1 framework available, while the one you are having the problems on only has 2.0.
I agree that it is an odd way to name files but it is the way. Not long ago I built a C# library that looked like a COM component for a co-worker to use in a VC6 application he was working on and after many problems of trying to use the web service it provided he finally asked what was wrong and after some investigating we found that he hadn’t renamed the config file as needed, it started out as YourAppNameHere.exe.config, but after we changed it all worked great.
P.S... sorry for the above... book.