BadImageFormatException – This assembly is built by a runtime newer than the currently loaded

Strange thing happened today. I upgraded one of the internal tool to .Net 4.0 without any issues but as soon as I attempt to debug/run the binary, I’ll see this exception:

System.BadImageFormatException was unhandled
Message: Could not load file or assembly SomeTool.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Normally you see this exception if the machine doesn’t have right run time installed. But this was obviously not the case. Changing build to x86 or x64 didn’t made any difference either. Next I ran peverify.exe which happily reported that there was nothing wrong with the binary image. Finally I needed to pull out the big guns, ask fuslogvw, which would show me if there are any dependent assembly binding that was failing. But that also didn’t produce any boom sounds.

So the last resort was to just meditate over the issue for few minutes. And that works. In a sign of enlightenment I saw app.config buried along with bunch of files and it had these lines:

<?xml version="1.0"?>
<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>

Aha! Apparently the app.config doesn’t get updated (may be because it was in TFS?) when VS did the 4.0 upgrade. As app.config didn’t had anything else, just deleting this file solved the issue. I do wonder how many people come across this gotcha.

Comments (17)

  1. Arne says:

    Solved a similar issue for me! Thanks!

  2. Christopher Fritz says:

    I experienced 100% exactly the same issue, going from 2.0 to 4.0.  I would never have thought to look in the app.config files, but sure enough about a quarter of them had v4.0 while the rest had v2.0.50727.  And coincidentally all of the v2.0.50727 are empty (not in use for holding any settings).

  3. illone says:

    Great, Thx!   I love google.

  4. Smitha says:

    thanks a ton.. u saved my day 🙂

  5. Adrian says:

    Bang! that was it!

    Troubled me for a while!

    Thank you very much

  6. Philip says:

    Thank you, we had the same issue and were wondering why… We had both versions in our app.config files.

  7. Y says:

    Thank you. This solved my problem.

  8. Klaus says:

    Saved my bacon today, thank you.

  9. OttoG says:

    Thank you for this post! It could have taken ages before I checked app.config, had I not read this.

  10. EK says:

    Thank you very much. This solved my issue! Big star for you for publishing this!

  11. Rashid Amin says:

    I'm not a developer but an integrator. I'm trying to connect from Citrix Provisioning Services MMC console to SCVMM version 2012 R2. I got the exact same error message as you did but I'm afraid, I could not find any resolution.

    Citrix requires that I install the SCVMM 2012 R2 console before I try to interface with SCVMM 2012 R2. I have installed it as well as ran a full Microsoft recommended updates. It appears the API for the version I'm connecting from will not interface with SCVMM 2012 R2. What I am confused about is, the Citrix software is offloading the API communication entirely to the SCVMM console installed locally on the server so the error is likely being presented by SCVMM. I figured I'd ask since it's identical to your error message but I don't particularly know how this can be corrected.



  12. rush222 says:

    If someone came to this threat due to an interface issue between Citrix Provisioning Services and SCVMM 2012 R2, then use this resolution:

    […]Create a file “powershell.exe.config” in the ‘C:WindowsSystem32WindowsPowerShellv1.0′ and C:WindowsSysWOW64WindowsPowerShellv1.0 with the below contents and restart the server.

    <?xml version="1.0"?>


    <startup useLegacyV2RuntimeActivationPolicy="true">

    <supportedRuntime version="v4.0.30319"/>

    <supportedRuntime version="v2.0.50727"/>



    I wish I came up with the resolution but the I came across it from the website under REFERENCE.


  13. ziggysprings says:

    thank you very much – ran into same issue

  14. maximus says:

    Great – It worked like a charm. i just removed the following line from the App.config file

    <startup><supportedRuntime version="v2.0.50727"/></startup>


  15. Milan says:

    I had the same issue. Ran the snippet from rush222, and started back up debug and it worked. Thanks 🙂

  16. Garrett says:

    This drove me crazy from midnight until 4am; thank you so much! Another gotcha was that I was building a Mono version of my application and I hadn't defined the necessary symbols at compile time (nor had #else directives to alert me of that fact), so some very important functionality was omitted from the execution path, haha.

Skip to main content