32bit MSI: Converting shortcut target path of 64bit app to 32 bit Path

I'm working on a deployment project (Wix based) which is used to deploy an application to run with AutoCAD and create shortcuts of AutoCAD's acad.exe while passing its own argument.

To achieve this, there is a Custom Action dll (C++) which iterate through Autocad's registry keys and get the "acad.exe" location and create/update the shortcut using MSI Api methods in MyInstaller.msi at run time.

Problem:

On x64 bit OS like Windows 7, Custom Action is reading the proper 'acad.exe' location from registry i.e. C:\Program Files\AutoCAD 2010\acad.exe, and update the shortcut properties in msi at runtime. But when msi finishes creating shortcut, the path is converted to 32bit program files i.e. C:\Program Files (x86)\AutoCAD 2010\acad.exe, which actually doesn't exists.

My Work 开发者_StackOverflowAround:

As my msi is 32bit (x86), so I created a separate Component with attribute Win64=Yes, and modified Custom Action to update/create shortcuts for this component. But still target path in shortcuts are being converted to C:\Program Files (x86).

I know if I convert my MSI for x64 OS, this might be solved, but at the present, I can't do such a big change.

Is there any way that a 32bit msi can create shortcuts containing paths of x64 OS?

Any help would be really be appreciated..

Thanks a lot.

---

You are swimming upstream against MSI on this one. (Although I can understand why. )

Officially MSI is never platform nuetral. I assume you are using a custom action to read the registry values because MSI's AppSearch/Reglocator will constrain you to the WoWSys64 node. After that, MSI will substitute even hard coded references to program files as part of an application compatibility approach ( basically microsoft assumes you didn't know what you were doing and that they know what you really meant to do ).

Unofficially- read this thread to find a hack that I figured out to work around this. The summary is I found that if you convert C:\Program Files\ to a short path ( C:\Progra~1 ) that MSI is no smart enough to figure out what you are referring to so it doesn't substitute the value.

http://www.joyofsetup.com/2010/03/27/wix-msbuild-v2-0-and-x64-systems/

Note, this a hack and there is no way of telling if Microsoft will 'fix it' in future releases. The only other approach I can think of is you to then not use the shortcut table and instead write custom actions to create the shortcuts for you.

If you don't want to swim against MSI, consider this workaround. Create a small 64bit EXE ( yes, you can deploy a 64bit or AnyCPU exe to Program Files x86 is a x86 MSI ) that acts as a front end launcher to AutoCAD. Make it query the registry table and find the file then launch it or display a message saying AutoCAD is unavailable if it can't be found.

If you do this you make your install far cleaner.

---

Ok I was able to solve it:

Problem was, 32bit MSI on 64bit OS, was converting paths (in shortcut table) to 32bit equivalent paths i.e. Our Custom Action dll was getting AutoCAD's path from 64bit registry key as C:\Program Files\AutoCAD 2010\ and then injecting this path to MSI's shortcut table and Directory table. But when MSI was writing the shortcut, it was converting it to C:\Program Files (x86)\AutoCAD 2010.

We can't have 64bit Components in 32bit MSI, but Vice Versa is possible i.e. We can have 32bit Components in 64bit MSI.

However, in my case, I have to use 64bit Components for shortcuts and other components would remain 32bit.

So I have converted my 32bit MSI to 64bit MSI adding Plantform=x64 in Package information. And declare the component as Win64=Yes.

And this solved my problem and now I'm getting proper paths in shortcuts.

Due to this, now I have 2 separate installer i.e. for each 32bit and 64bit respectively.

Best regards

Farrukh