Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / April 2006

Tip: Looking for answers? Try searching our database.

CLR version mismatch

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
PRASENJIT BURMAN - 01 Apr 2006 12:52 GMT
I have a managed application compiled on .net 1.1 calling a unmanaged ACtive
X control which in turn uses a managed extension C++ COM dll compiled on .
Net 2.0. This causes the following exception to be generated in the managed
app

System.IO.FileLoadException

Common Language Runtime Internal error: 0x80131107

This results due to the a lower version CLR version already loaded in to the
managed applciations process. This situation can be rectified by changing
the application configuration file (supportedRuntime element) to specify
that the 2.0 .Net framework CLR should be loaded. The problem is that the
Active X control is used by many  other applications and it is not feasible
to update the app config file each time the Active X control is moved to a
higher version of the framework. Is there any way to specify which version
of a managed COM component should be loaded for a particular version of the
CLR. Any other solution to this problem.

Prasen
Willy Denoyette [MVP] - 01 Apr 2006 20:55 GMT
The problem has nothing to do with the AX control, by default your
application will load the version of the CLR that it was build against
(v1.1), but your ME C++ DLL was built with V2 which means it requires V2 of
the CLR. So you always need the config file supportedRuntime element
specifying V2.

Willy.

|I have a managed application compiled on .net 1.1 calling a unmanaged ACtive
| X control which in turn uses a managed extension C++ COM dll compiled on .
[quoted text clipped - 16 lines]
|
| Prasen
PRASENJIT BURMAN - 04 Apr 2006 15:11 GMT
Is it possible to resolve this problem using the concept of side-by-side
assemblies?
Wherein each application (using the COM comps) will have an application
manifest listing the appropriate version and name of both the dependent  
native COM and managed COM component.

The native COM and managed COM component can be installed as side-by-side
shared assemblies.

In this scenario the application will bind with those assemblies which have
been built using the same .Net framework.

Prasen

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.