New Assembly, Old .NET (and Vice-Versa)
I typically recommend that you build and test your assemblies against the same version of .NET that you will be running them against. That way, you'll have correct references and avoid surprises from behavior differences between builds.
Older assembly, newer .NET
But, sometimes you don't run against the same version that you built against. For example, the latest available CLR is the default when interop causes it to be loaded. Or, if the version of the CLR the assembly was built against is not available, the latest version can also be used instead. If there is a compatibility problem with that for your application, you can force the use of a preferred CLR version by using an app.config.
Compatibility
Yes, there are going to be behavior differences between versions - no way around it. It is the .NET team's goal to be as backwards compatible as realistically possible between versions. But, some changes are required - new features are added which sometimes require (hopefully minimal) behavior changes in other features. If we were required to never break any app, ever, we wouldn't be able to fix any bugs or add any features for fear that someone, somewhere relied on the broken behavior in some strange way. As Dll Hell has shown in the past, new versions of components aren't really compatible. The only guaranteed 100% compatible version is the same one you tested against.
V2+ assembly, older .NET
Say you see a BadImageFormatException for hresult 0x80131107 (CLDB_E_FILE_OLDVER) with message "Version [...] is not a compatible version." That means that you've tried to load an assembly built against a newer version of the CLR than was running.
This fails because new files can't be opened on an older CLR that does not understand them. You will need to either use the v2 CLR to load the v2/v1 assemblies, or load only v1 assemblies on the v1 CLR. That's just good practice, anyway. If you try to use an older .NET than you built against, a method you built against may not exist, etc.
Comments
Anonymous
January 26, 2005
The comment has been removedAnonymous
January 26, 2005
The comment has been removedAnonymous
January 27, 2005
The comment has been removedAnonymous
January 27, 2005
Paul: Consider the add-in case from my last comment. With your suggestion, if the v1 add-in is loaded first, causing the v1 .NET to be loaded, then the v2 add-in is broken. The feature it requires may not exist in v1. Even if you somehow force the v2 add-in to be loaded first (which may not be an option for many apps, since they may not even know about the v2 add-in yet), then the v1 add-in still needs to deal with the v2 .NET.
That's why interop has chosen to just load the latest available .NET up front, and then that can be overridden by app.config. But, we do take compatibility problems seriously. If you run into them, especially with a beta, please give feedback in the appropriate beta forum. We do listen and try to take appropriate steps. (But, please don't email us directly. http://blogs.msdn.com/suzcook/archive/2003/12/05/57253.aspx )Anonymous
April 18, 2005
The comment has been removedAnonymous
July 31, 2005
The comment has been removedAnonymous
October 27, 2005
It all makes sense but what bothers me is the rather cryptic message. "Version [...] is not a compatible version." Tell me there is more for the user if we just return the error message for users. It's better than some. How about a little runtime help such as "This is most likely due to...for more information, refer to http://....".
Thanks for taking the time to mention the issue.
-VinceBAnonymous
March 05, 2006
I have just run into the dreaded CLDB_E_FILE_OLDVER error message.
It would make life so much easier if we could use tools such as tlbimp to target a specific version of the framework.
As someone being kind and distributing my COM object with a .NET assembly I gain little advantage in forcing my users to upgrade to .NET 2.0 (Significantly larger code base, more testing etc. if they haven't already got it) when I don't require the framework for my core application which is written in C++.
I can just as simply target 1.1 and rely on the 2.0 framwork to work with my v1.1 targeted assembly.Anonymous
March 09, 2006
Is there a way for me to know which CLR was used to load a DLL while in Debug mode?
My scenario is 2.0 exe calls an 1.1 dll. I am sure that when the DLL is loaded, 1.1 CLR is loaded, but just wanted to confirm the same in debug mode by setting a break point in the DLL. Any way I can achieve it?Anonymous
May 04, 2006
I am trying to debug into a v1.1 assembly from VB6 and it was working fine before I installed framework v2.0 side-by-side v1.1. I cannot now attach to the VB6 process and have tried creating app.config files for the assemblies but still to no avail, I am using:
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
in the config file. The only way that it appears that I can go back to cross debugging in VB6 is to uninstall FW 2.0 - any ideas ?
Regards MarcusAnonymous
May 29, 2006
Marcus
I have the same problem. I suppose you build Class Libraries like we do, to be used from VB6.
Try to add
<startup>
<requiredRuntime version="v1.1.4322" />
</startup>
to your config file.
I worked for me, the problem is that we run the COM dlls in COM+, so I have to create a dllhost.exe.config file...
BR
Anders GAnonymous
June 13, 2006
This might seem a silly question but here i go.
i am having a problem with serialization between client in version 1.1 and server in version 2.0 Is it possible to tell the clr to use a specific assembly in clr version 1.1 (i.e. on the server side it should clr 1.1 for a particular assembly)
I have tried to startup tags to perform this operation but i receive a BadImageFormatException.Anonymous
December 11, 2006
PingBack from http://www.colinneller.com/blog/CLR11CLR20Interoperability.aspxAnonymous
August 10, 2009
Hi Is the number of .net runtime enviornment=number of .net applications currently running?Anonymous
April 27, 2010
The comment has been removed