I'm writing a plug-in for another program that is based on a public .NET API. Typically these plugins are made by creating a class library DLL that references the API assembly. Then a command class is created by inheriting from a base command class in the API assembly. The application is then set to reference the plug-in DLL file, and is then also responsible for actually firing up the custom command class when the user requests it.
However, now I'm trying to automate some code generation through System.CodeDOM
, and want to create a simple console application that automatically generates new Class Types based off of types with in the API assembly.
Yet, when I try to run my application I get the following exception.
System.BadImageFormatException was unhandled Message: Could not load file or assembly 'RevitAPI, Version=2011.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Usually I need to set the target framework of a plug-in assembly to 3.5. Yet now I've found that the error above goes away if I set the target framework of my console application to 2.0. However, my console application already references other class libraries of mine that have their target framework set to 3.5. And I'd really rather not rewrite them around the 2.0 framework.
It's possibly a 32 - 64 bits mismatch.
If you're running on a 64-bit OS, the Assembly RevitAPI may be compiled as 32-bit and your process as 64-bit or "Any CPU".
Or, the RevitAPI is compiled as 64-bit and your process is compiled as 32-bit or "Any CPU" and running on a 32-bit OS.
If you use IIS, Go to the Application pool Select the one that your site uses and click Advance Settings Make sure that the Enable 32-Bit Applications is set to True
I was having problems with a new install of VS with an x64 project - for Visual Studio 2013, Visual Studio 2015 and Visual Studio 2017:
Tools
-> Options
-> Projects and Solutions
-> Web Projects
-> Check "Use the 64 bit version of IIS Express for web sites and projects"
These suggestions are accurate, but I wanted to add a note. I was stuck simply because I had multiple publishing configurations. I was editing the "Debug - Any CPU" and then deploying the "Debug - x64" configuration. Make sure you are editing and deploying the same configuration. Verify this by clicking the "Settings" tab after you begin publishing and the "Publish Web" dialog pops up. Make sure it matches the configuration you edited. (That's 4 hours of my life I will never get back!)
I had the same issue when getting my software running on another machine. On my developer pc (Windows 7), I had Visual Studio 2015 installed, the target pc was a clean installation of Windows 10 (.Net installed). I also tested it on another clean Windows 7 pc including .Net Framework. However, on both target pc's I needed to install the Visual C++ Redistributable for Visual Studio 2015 package for x86 or x64 (depends on what your application is build for). That was already installed on my developer pc.
My application was using a C library, which has been compiled to a C++ application using /clr and /TP options in visual studio. Also the application was providing functions to C# by using dllexport method signatures. Not sure if the C# integration leaded to give me that error or if a C++ application would have given me the same.
Hope it helps anybody.
For running it on any CPU either 62 bit or 32 bit follow these steps: Right click on the name of the project in Solution Explorer> Properties>Build and have these under Configuration: Active(Release), Platform:Active(Any CPU) and Target:x86. and just beside the Run button Select option Release and Any CPU from the options. And then Save it and Run.
i have same problem what i did i just downloaded 32-bit dll and added it to my bin folder this is solved my problem
https://i.stack.imgur.com/U6lJe.png
i was trying to load dll that had x86 architecture . in c# project i described platform target as x86 and got rid of the error
Please also note that the version of referenced dll file(s) which is in use is very crucial. I had almost the same problem with "Microsoft.WebView2.FixedVersionRuntime.101.0.1210.39.x64" when I tried to use the WebView2 component in the MMC Snap-Ins with types of "HTMLView" or "FormView".
I just copied the dll file (in my case WebView2Loader.dll, version 1.0.1248.0, size=157640 bytes) in a proper path that was accessible for the project (you could just put it beside your project output files first to test it) and then WebView2 browser started to function as expected. Microsoft error messages sometimes (at least in my case) was a little bit misleading and did not convey enough and to the point information.
I received "BadImageFormatException" that normally occurs when you mix platform targets (for example using a dll file compiled in X64 in an application that targeted for x86 or vice versa) or mix native code and .NET but that was not my problem at all. I hope this help one who may stuck in.
Success story sharing