ClickOnce: BadImageFormatException when running x86 package on 64 bit windows

My .NET 2.0 application imports unmanaged 32 bit dll. The dll is loaded (first interop call happens) when user opens a file via a dialog within the application.

When I deploy the application via clickonce with target platform "Any", users on 64 bit windows get BadImageFormatException when trying to open files from the application (at the moment the unmanaged dll is loaded). I understand this is due to incompabible bitness of the 64 bit process and the 32 bit unmanaged dll.

I have redeployed the application using x86 as target platform. As I understand it, this should solve the bitness problem.

BUT

When I run the deployed application built for x86 on 64 bit system, I now get BadImageFormatException immediately before the application even starts. Tested on at least three 64 bit machines. On 32 bit machines, it works with no problem.

When I run the application directly from VS (or not directly, just a normal build, not going via ClickOnce), there开发者_开发问答 is no problem on 64 bit windows when using x86 target platform. The application starts and user can load file - the interop call succeeds.

I have been debugging this for 2 days straight with no result - I have tried on different computers. It seems to consistentnly work on one of the computers I have tried. However, I do not have permanent access to this computer.

I have managed to build the ClickOnce deployment on my computer once and it worked on a 64 bit machine. This was single of maybe 100 tries! Nothing has changed, the only changed variable was that I did the successful build immediately after computer restart.

I did clean/rebuild/restart VS/restart windows MANY times. I have reinstalled VS 2008 and now also the whole OS, it did not help.

---

EDIT: I have just managed to get one good build (out of next 100 :)) and did comparison between the deployed directories. The source of the problem is that ClickOnce generates the wrong target platform in the manifest of the main .exe:

<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />

processorArchitecture should be x86.

So the question is how to consistently force VS to generate the correct processorArchitecture in the manifest when deploying.

Can anyone help please?

---

This was resolved by installing VS 2008 SP1 on 64 bit Windows 7. VS2008 SP1 on XP had the problem on two machines I have tried with.

---

I had this problem as well, using VS2008 SP1. In my case I had a 32 bit DLL which had to be compiled as 32 bit and an application that was using it in the same solution. Even though I specified X86 as the build target for the release build, when I published a 64bit application was compiled and included in the installer. I found a slightly brutal solution to the problem: Go into the configuration manager and remove all possible configurations except the one that you want it to build (Debug and release versions). After doing this I found that the clickonce installer was generated with the correct application.

I hope this helps someone else, I have been battling this problem on and off for months.

---

I'd suggest to use Reflector to open the main exe deployed by ClickOnce and see the dependencies to make sure you are not deploying the 64 bit version of the dll by mistake.

---

You must resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

---

Sometimes the ClickOnce publishing process seems to cache old files from previous Any CPU or x64 builds. Doing a Clean and Rebuild All didn't fix this problem for me. I needed to delete all of the bin and obj folders from my projects and reopen Visual Studio.

---

We ran into this problem and determined that the subdirectory of the user profile to which ClickOnce deployed our application must have become corrupted, because we were able to deploy the application successfully with ClickOnce when logged in as a different user on the same machine.

We were able to solve the problem simply by deleting the subdirectory of C:\Users\<user>\AppData\Local\Apps under which ClickOnce was deploying our application. In our case, this was C:\Users\<user>\AppData\Local\Apps\2.0.