WiX, MSBuild v2.0, and x64 systems

WiX v3.0 and v3.5 executables are available in .zip form and x86 and x64 .msi packages. The x64 .msi package was originally created because we need to install the WiX targets and tasks for 64-bit MSBuild into a 64-bit directory, something that’s not supported for x86 packages. Late in the WiX v3.0 development cycle, Jason made a change that lets 64-bit MSBuild use the targets and tasks in the 32-bit directory tree. Unfortunately, the special property used to allow that is present only in MSBuild v3.5, not MSBuild v2.0, so we still create the x64 .msi package.

Creating the x64 .msi package isn’t a huge burden on us but it’s led to some confusion, so we’d like to get rid of it. If you use 64-bit MSBuild 2.0 and the x64 WiX .msi package, please respond in the comments. If you use MSBuild 3.5 or the .zip WiX package or by checking WiX in to your source-control system, you’re not affected and can use the x86 WiX .msi package.

14 Replies to “WiX, MSBuild v2.0, and x64 systems”

  1. Would it be possible to have a custom action that resolves the 64bit location of the msbuild directory and just use the CopyFile element to duplicate the 32bit component resource to it if it exists?

  2. Currently we’re using the x64 Wix 3.0 MSI with MSBuild 2.0, but we’re switching to MSBuild 3.5 – so no prob on our side. Personally, I prefer removal of the additional package since it doesn’t add much value and there are workarounds available. So please, go for it!

  3. I never tried it, but I’m wondering to myself, why not? 64bit registry I could understand but what is so special about C:\Program Files that it physically can’t be accessed? I would have figured the limitation was only that ProgramFilesFolder wouldn’t resolve to it not that the installer physically couldn’t write to it.

  4. Hmmm, I’d have to find some free time to play with this. Until then, VS2008 and soon VS2010 rocks. We don’t use VS2005 anymore and I have no need to support it on x86 let alone x64. 2005/2.0 was a nice combination but 3.5 is just that much better.

  5. Hmmm, I pasted an XML example but it was filtered. Basically I found through observation that if you set a property to C:\PROGRA~1 that FileCopy would work.

    The reply to this is probably it’s a windows installer bug and don’t rely on the behavior, but I did observe that a Type 1 custom action to resolve the fully qualified short name path of the 64bit MSBuild folder could sneak past MSI and get the file duplicated to the correct location.

  6. I don’t know what’s more disturbing: That it works or that you discovered it. 🙂 We’d need a custom action to find it (since it might be PROGRA~1 or PROGRA~2), though, and it might not work anyway, since short filename generation can be turned off.

  7. You have to understand, I’m a Texan. We don’t like hearing ‘it can’t be done.’. 🙂 Shouldn’t be done is one thing, but can’t be done is just an invitation to figure out how to do it out of spite.

    Seriously, the part that is disturbing to me is that while I can understand MSI providing different answers for ProgramFilesFolder depending on context, I don’t like that MSI would go out of it’s way to transform a path that I specifically set to be what I expect it to be.

    I’m not even sure where that behavior is documented.

    I agree on the need for a CA. You could also condition it to fire only if SFN isn’t disabled. This way if the property never gets set, FileCopy won’t do anything.

  8. It’s consistent with the “only 64-bit packages can touch 64-bit stuff” rule, however; they’d have to do something to redirect the file system or else anything done via custom actions would likely be broken. The alternative would be to have an opt-out but they didn’t seem too interested in enabling multi-platform packages.

  9. I find it dissapointing that this wasn’t a priority. x64 is starting to become mainstream and I see problems ahead. For example, PowerShell 2.0 has installers for each combination of platform and language. It’s then a setup prereq for other things like SQL 2008. This really needlessly makes the chaining and servicing story very messy.

    As ISVs make the jump from x86 to x64, I see a lot of confusion and chaos coming.

  10. Please bring more light in this!

    VS is a 32 application. WiX integration can reduced to 32bit, if we can build our installations.

    …the built installation is 32bit…

    Can a 32bit setup install 64bit applications, where are the traps and borders?

    Win7 will be the last 32bit OS, I think.

    Can you write something about the differences of 32/64bit installers and installing 32/64bit applications?

    I used the 64bit msi version. Nice to get it again.

Comments are closed.