17

I swear the more Microsoft "evolves" Visual Studio, the more ignorant the entire process becomes.

I have a Windows Service with 3 class libraries in it. I went into the properties for each class library and set the platform target to x64. I did this same thing to the Windows Service as well as to the Test Console project I added to verify everything.

I can run the console application on my Windows 2008 R2 x64 server with no issues but the stupid installer keeps bombing out and telling me that I have a bad image. I did ensure that I had set the target platform of the installer to x64.

I have no idea idea was this stupid thing would be bombing out and would really appreciate any insights. I do reference other DLLs and those might be x86 but I thought if the main libraries were set properly that things would work...

Ken Tola
  • 671
  • 1
  • 8
  • 18
  • 4
    You may want to watch the words you use to describe this issue as it's entirely possible it's an error on your part rather than anything that is Microsoft's fault. – Jesus Ramos Apr 23 '12 at 05:13
  • 1
    Sounds like someone has an architecture mismatch... –  Apr 23 '12 at 05:14
  • Since I have been working with MS technology since the early 90's, I think I am qualified to attest to its rapid decline in overall usefulness. – Ken Tola Apr 23 '12 at 05:23
  • As for the architecture mismatch, I completely agree but I cannot figure out where the issue is stemming from. Like I said, I ran through every possible config option and set everything to x64. External DLL references - being called via DLLImport calls - should NOT be affecting the installer. I can run the exact project as a console application without issue but everything fails when trying to install a Windows Service. – Ken Tola Apr 23 '12 at 05:25
  • All of the documentation I have read says two things. First when forcing a Windows Service into x64 mode you need to reference the .NET DLLs directly from the x64 folder instead of through the .NET tab as those are all x86 references. Second it is actually NOT recommended to set the platform as the service will run x64 if that option is available on the target server. Prior to reverting everything back to "Any Platform", can somebody please verify that the service would run x64 under the "Any Platform" scenario? – Ken Tola Apr 23 '12 at 11:33

3 Answers3

29

I have finally figured this out – it has NOTHING to do with architecture, references or any other nonsense and everything to do with the installer itself. As this article explains – the Visual Studio Installer, by default, uses a 32 bit DLL and that is what causes the failures.

To overcome this problem, simply follow these steps:

  1. Make sure that you go into the Properties ⇒ Build tab for every project and set the Target Platform to x64
  2. Click on the name of your Installation project and then Properties and ensure that the Target Platform is x64
  3. Build your solution – if the solution does not compile, right click and Unload Project and then Load Porject for those projects whose references fail.
  4. Go here and download and install the 7.0 INstaller SDK
  5. Go into the C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin folder and install Orca by double-clicking on the Orca.Msi file
  6. Run Orca and open your project's MSI folder
  7. Select the Binary table
  8. Double click the cell [Binary Data] for the record InstallUtil
  9. Make sure "Read binary from filename" is selected
  10. Click the Browse button Browse to C:\Windows\Microsoft.NET\Framework64\v4.0.30319
  11. Select InstallUtilLib.dll
  12. Click the Open button and then the OK button

That is it - save your MSI file in Orca and then deploy it – the x64 installation should work without any further issues.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Ken Tola
  • 671
  • 1
  • 8
  • 18
  • 8
    By the way, thanks for the down votes you MS babies - this is a legitimate issue along with a host of other MS issues and the fact you cannot stand credible criticism speaks volumes about you. – Ken Tola Jul 20 '12 at 18:10
  • 2
    Thanks Ken, finally a working solution. I have a question. Would it be possible to do this automatically as a post built event? Manually doing this for dozens onf installers every release is time consuming... – KenGey Nov 17 '14 at 10:24
  • [Orca 5.0.7693.0 (2.1MB)](http://goo.gl/EOCZi) without the whole SDK from [Orca 5 – msi editing tool for Windows 7](http://myserverissick.com/2011/04/orca-5-msi-editing-tool/) – Michael Sandler Nov 19 '14 at 09:34
  • 2
    @KenGey - yes you can automate this as a post-build event; see my comment under http://stackoverflow.com/a/6797989/1843329 . Or go directly to https://code.msdn.microsoft.com/windowsdesktop/CSBrowserHelperObject-59c189a2#content for details. – snark Nov 22 '16 at 15:37
  • Don't know how you went around and found this solution but it works brilliantly. – Talha Imam Oct 03 '18 at 12:56
1

I just ran into this issue myself, in Visual Studio 2017, building an installer for an x64 version of an application that's been x86 for a long time.

I don't doubt that Ken's answer is definitive, but it occurred to me that as the Custom Actions are called by the installer, not by the installed application, there is no need, in my case at least, for the project containing the Custom Actions to have the same bitness as the rest of the application, as its classes are never instantiated by the application itself.

So I changed the platform for that project alone back to x86, and rebuilt the installer.

It all 'just worked'.

This depends, of course, on having Custom Actions that are completely isolated from the rest of the solution. Quite a relief not to have to use Orca however.

ChrisA
  • 4,163
  • 5
  • 28
  • 44
1

This error happened to me installing a .Net 4.5+ service to a 64-bit machine.

  • The installer was set to x64
  • The service project build platform was set to x64

Installation fails with a BadImageFormatException.

For me, the solution was to go to the service project properties, and change the build platform to "Any CPU", and also uncheck the "Prefer 32bit" checkbox that was checked by default (see also what does it mean).

ciencia
  • 456
  • 4
  • 11
  • Unchecking "Prefer 32 bit" worked for me in Visual studio 2019. Was having BadImageFormatException. I spent lot of time thinking of some reference problem and there might be some problem with 32 bit to 64 bit incompatibility or vice versa. So unchecking this option just worked out. – Yugendhar Anveshra Nov 12 '21 at 07:26