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.


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 (17)

  1. Sam says:

    Interesting post.

    You mention it is a goal of the .NET team to maintain backwards compatibility as much as possible.

    I cant help wondering why this is important?

    "new versions of components aren’t REALLY compatible"

    If there is a risk, however small, that a companies application may not perform correctly when run against a later version of the framework then they are very likely to bundle an installer for the appropriate version of the runtime with their product and provide an app.config file.

    Correct me if I’m wrong, but doesn’t that mean there is little requirement for backwards compatibility with regard to execution of assemblies compiled against previous versions?

    And then what about source code compatibility?

    A situation would arise if a company decided to switch to a later version of .NET during development. In that case, the developers would be forced to modify their source code since it would not compile against the more recent framework "out of the box".

    Personally, I would be perfectly happy to modify my code if it meant I could take advantage of a more powerful framework which was still as coherent as, or possibly more coherent than v1.0 with regard to content.

    Or am I missing an important point here?

  2. Paul Gunn says:

    You mentioned the issue with interop loading the newest framework version.. This has been pretty problematic for me recently.

    I have been on an installation project where we are writing custom action dlls in managed c++. The dll entry points have the same behavior as interop (picking the newest framework version) and this bit us as a result of some changes 2.0 made regarding how xmlserialization plays with assembly loading.

    We found a workaround that works with both framework versions, but compatibility is still a concern. Obviously in this case we can’t use a app.config file – since the app in question is msiexec.exe (the microsoft installation program).

    Has there been any thought to having the framework version used in interop be based on the assembly being loaded for interop? I would imagine it quite common that the component writer may not have control over the originating Exe, nor should the consumer of the component really need to care what framework the component wants.

  3. Suzanne says:

    Sam: It’s not that simple. For instance, there are cases where components built against different .NET versions need to run against the same .NET. The components may be add-ins, where the host has the option to choose the .NET version, but the individual add-ins would not. If there was a v1 add-in and a v2 add-in in the same process, running the v2 .NET, then we’d hope that the v2 .NET is backwards-compatible, or else the v1 add-in would be broken.

    Regarding source code backwards-compatibility: yes, we do take steps to make that just work as well. But, again, there are times when it’s not realistic to try to make it perfectly compatible. And, yes, it’s not as breaking as a binary compatibility breaking change, as developers can update their sources when they recompile…unless they recompile at runtime.

  4. Suzanne says:

    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. )

  5. One oddity I noticed in playing with VS05b2 this weekend was the GAC behavior. I removed an older copy of the CTP, but it left some assemblies in the GAC. For example, Microsoft.VisualStudio.TextManager.Interop.8.0. VS05b2 installed the same assembly, same version (, same public key token, same culture. The only difference was the timestamp of the assembly. I thought the GAC was supposed to protect against junk like that. What am I missing?



  6. diegov says:

    I don’t know what is wrong, but I have seen related oddities, and I think it is worst than dll hell.

    Even if I uninstall the 1.1 component of the GAC and add the 2.0 version, many times, with crossed fingers, at different times of the day, and with recompilation, I don’t get to debug it anymore. Now I remmember mama said "avoid the GAC"… or was it Chris Sells?

  7. VinceB says:

    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.


  8. Mark Heaton says:

    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.

  9. Sriram says:

    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?

  10. Marcus Arraya says:

    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:


       <supportedRuntime version="v1.1.4322" />


    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 Marcus

  11. Anders G says:


    I have the same problem. I suppose you build Class Libraries like we do, to be used from VB6.

    Try to add


    <requiredRuntime version="v1.1.4322" />


    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…


    Anders G

  12. Clinton says:

    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.

  13. Asif says:


    Is the number of .net runtime enviornment=number of .net applications currently running?

  14. Marc says:


    we see the error:

    System.BadImageFormatException: Could not load file or assembly ‘’ or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

    When we add the Publisher Policy Assembly file to SharePoint 2010.  We are using the "al.exe" from 7.0a of the SDK to build our asseblies.  Any ideas about what might be happening?