none
Error 1001. Could not load file or assembly. ...built by an assembly newer than the currently loaded runtime...

    Question

  • Dear DeployersI have a C# managed code application under VS2010 and NET 4.0 that has a deployment Solution that builds two .msi's, the first Tempest.Deployment.msi for the base application, and the second Tempest.DeploymentXXX.msi that has no central .exe but simply installs some extra file directories.

    Everything is configured for Release/AnyCpu/NET4.0.  And both builds and installs are run under Windows 7 Enterprise 64-bit.

    Both .msi's load a Custom Action library called CustomActions.dll which sets some Environment variables and a registry entry.  Both .msi's  build without error.  And when it comes to the install, Tempest.Deployment.msi -- carrying the base application -- loads CustomActions.dll without difficulty.  But when Tempest.DeploymentXXX.msi is run, I get the following error:

        Error 1001. Exception occurred while initializing the installation:
        System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program
        Files\DRS-AMTC\Tempest\TempestCustomActions.dll' or one of its dependencies. This
        assembly is built by a runtime newer than the currently loaded runtime and cannot be
        loaded.

    This is a puzzle since the first .msi has no trouble loading that .dll, and because everything involved in the process are NET 4.0 and 64-bit machines.

    Any ideas?

    (Is there any chance that the cause is related to the only significant apparent difference between the two .msi's, namely that the second one installs no application .exe but simply a group of files?)

     

    Peter Schwenn

     


    schwenn
    Tuesday, March 08, 2011 10:20 PM

All replies

  • Unlike .NET 3.5 and previous version of .NET, .NET 4.0 is a new .NET core. Other assembly built target to .NET 3.5 or lower version uses 2.0 core. When you build your app in VS 2010 and target to .NET 4.0, you should check each assembly to make sure they are also built under 4.0.

     

    The assembly you need to check is TempestCustomActions.dll and its dependence. The way to do it is load that dll with .NET Reflector (http://www.red-gate.com/products/dotnet-development/reflector/). There is one field in reflector shows “Target Runtime” when the assembly is selected. 


    Senior Support Engineer
    Wednesday, March 09, 2011 9:06 AM
  • Myexp,

     

    Thanks for your response.

     

    NET Reflector indicates that TempestCustomActions.dll has Target Runtime v4.0.30319 and Platform Target "Any".  Those correspond both to the version of NET runtime on the install machine (also 4.0.30319), and to the Target NET Framework (4.0) of the Properties of TempestCustomActions.dll .  So the build and its output and the install runtime seem correct.

     

    To repeat: This error is a puzzle since the first .msi has no trouble loading that same TempestCustomActions.dll, and because everything involved in the process (build and install) are NET 4.0.30319 on 64-bit machines running 64-bit Windows 7.

     

    Regards,

    Peter Schwenn

    schwenn
    Wednesday, March 09, 2011 5:04 PM
  • > Error 1001. Exception occurred while initializing the installation:

        System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program

        Files\DRS-AMTC\Tempest\TempestCustomActions.dll' or one of its dependencies. This

        assembly is built by a runtime newer than the currently loaded runtime and cannot be

    loaded.

     

    So what about the assembly that invoke the dll? Custom action is invoked by an assembly located in System32 folder based on my mind. .NET 4.0 is not shipped with Win7. I think that assembly which invoke your TempestCustomActions.dll is .NET 2.0 assembly.

     

    2 ways to fix it

    1.       Set .NET 4.0 as prerequisite for your setup project and click Setup.exe (not msi) to install the application.

    2.       If you do not use any new feature come with .net 4.0, build all assembly as .net 2.0 assembly. 


    Senior Support Engineer
    Thursday, March 10, 2011 1:24 AM
  • Deployers,

     

    As I indicated, the same version of NET 4.0 is installed on the Win 7 install machine as is used on the build machine, and ALL my prerequisites, including for the setup project are set to NET 4.0. 

    (And since the base application .msi does successfully load the NET 4 CustomActions.dll its clear that NET 4.0 is installed on the install machine and can be used -- the base application also runs properly.)

     

    I have tried clicking Setup.exe instead of the .msi but that makes for no change in the error.

     

    Peter Schwenn.


    schwenn
    Thursday, March 10, 2011 6:36 PM
  • Hi Peter,

    Not sure if you are still having the problem but I had the same issue and this link helped fix it. 

    http://www.alexjamesbrown.com/uncategorized/deploying-net-4-project-error-1001-system-badimageformatexception/

     

    I had to change the Launch Conditions to point to new version of .net.

     

    Hope this helps

     

    David

    Thursday, July 07, 2011 1:32 AM
  • I faced similar issue today for a windows service I targeted to install in a x64 bit environment. Originally I configured everything to run under x64 bit platform, but I faced the same issue.

    To resolve it, I had to change the service project to run in “Any CPU” and the installer project to x64, then only the problem got resolved.

    [Hope this would help someone in future…]

    • Proposed as answer by Ken Beard Friday, July 06, 2012 2:23 PM
    Monday, October 03, 2011 11:08 AM
  • I faced similar issue today for a windows service I targeted to install in a x64 bit environment. Originally I configured everything to run under x64 bit platform, but I faced the same issue.

    To resolve it, I had to change the service project to run in “Any CPU” and the installer project to x64, then only the problem got resolved.

    [Hope this would help someone in future…]

    You sir resolved an issue I was having for a whole half a day!

    Thank you very much!

    Thursday, May 31, 2012 6:51 PM