views:

138

answers:

4

I have a .NET app which works in 32 and 64 bit. I would like to write one single installer that installs to c:\program files, not c:\program files(x86) regardless of the platform.

From this link: http://msdn.microsoft.com/en-us/library/w1behyzx(v=VS.90).aspx it doesn't look possible. Is it the case?

+1  A: 

If your app works in 32 and 64-bit, it is 32-bit and therefore it goes in the (x86) folder.

Daniel DiPaolo
Incorrect. If target architecture is not specified when a .Net app is built, it is compiled to architecture-independent IL assembly. When such app is started on the user computer, the CLR compiles it just-in-time to a native machine code for the platform on which it is run. On 32-bit OS, it'll be JITed as a 32-bit, but on 64-bit OS it will be JITed as a 64-bit app.
Franci Penov
I was just going to post that, but Penov beat me.
wtaniguchi
Aha, did not know that and always assumed anything that ran in 64-bit and 32-bit was just running in 32-bit emulation on the 64-bit architectures which is why they were segregated like that.Will leave the response so your comment can be seen.
Daniel DiPaolo
+5  A: 

According to How to: Create a Windows Installer for a 64-bit Platform:

To distribute a .NET Framework application both to 32- and 64-bit platforms, build two MSI packages, one targeted at a 32-bit and the other a 64-bit computer. The user can install the 32-bit setup project package and it will most likely run as a 64-bit application, only the 64-bit setup project will install to the "Program Files64" directory.

Not the best experience, but works.

Update: The usual way people deal with their desire to avoid two installer packages is to produce one setup executable, which packs both installers and choose the correct one on the fly.

You can just create a quick C# (though now you have the problem of bootstrapping it on machines without .Net. yeah, are there such machines yet? :-)) or C++ executable yourself that detects the platform it runs on and launches the msiexec process with the proper .msi extracted from the executable resources or downloaded from a web siter.

Or this SO question's accepted answer talks briefly about that and mentions a third-party tool called Advanced Installer, that can help you with this. Note that I have not tried that tool and I can't vouch for it, theI just mention it for mere reference; you'll have to evaluate it on your own. :-)

Franci Penov
+1: You beat me to the link. I was going to answer about the same.
dboarman
That's exactly what I wanted to avoid: two distinct msi packages.
tom greene
I absolutely understand your desire, but just because you desire for something, that won't make it more feasible. At least not with MSI. You might consider alternative installer engines, but then you risk that installer engine not following all the OS guidelines properly.
Franci Penov
If you are saying it's not possible, I'll accept it. Let' s if someone comes up with a solution. If not, your answer will be the correct one.
tom greene
it is possible to have one deployment package; it's not possible to have one MSI. Your package will have to be a custom .exe that packs the two MSIs and chooses the right one at execution time.
Franci Penov
A: 

This link http://msdn.microsoft.com/en-us/library/cd7a85k9%28v=VS.90%29.aspx (referenced in the link you posted) has this section: To install files to the Common Files, Program Files, or System folder on a 64-bit platform.

This should help you out, as long as you target the x64 platform and doesn't have any references to libraries that are x86 only.

wtaniguchi
A: 

Hi tom,

I use WiX for installation packages. Please review the following article to see if it fits your requirements:

Example WiX-based setup that can be used to build both 32-bit and 64-bit MSIs

Muse VSExtensions