32位MSI:将64位应用程序的快捷方式目标路径转换为32位路径

发布于 2024-09-10 12:11:05 字数 757 浏览 10 评论 0原文

我正在开发一个部署项目(基于 Wix),该项目用于部署应用程序以与 AutoCAD 一起运行,并在传递其自己的参数时创建 AutoCAD 的 acad.exe 的快捷方式。

为了实现这一点,有一个自定义操作 dll (C++),它循环访问 Autocad 的注册表项并获取“acad.exe”位置,并在运行时使用 MyInstaller.msi 中的 MSI Api 方法创建/更新快捷方式。

问题:

在 Windows 7 等 x64 位操作系统上,自定义操作正在从注册表(即 C:\Program Files\AutoCAD 2010\acad.exe)读取正确的“acad.exe”位置,并更新快捷方式属性运行时在 MSI 中。但是当msi完成创建快捷方式时,该路径被转换为32位程序文件,即C:\Program Files (x86)\AutoCAD 2010\acad.exe,而该文件实际上并不存在。

我的解决方法:

由于我的 msi 是 32 位 (x86),因此我创建了一个属性为 Win64=Yes 的单独组件,并修改了自定义操作以更新/创建该组件的快捷方式。但快捷方式中的目标路径仍然被转换为 C:\Program Files (x86)。

我知道如果我将 MSI 转换为 x64 操作系统,这个问题可能会得到解决,但目前我无法进行如此大的更改。

有什么方法可以让 32 位 msi 创建包含 x64 操作系统路径的快捷方式吗?

任何帮助将不胜感激..

非常感谢。

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 Around:

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不喜欢何必死缠烂打 2024-09-17 12:11:05

在这方面你正在逆流而上对抗 MSI。 (虽然我可以理解为什么。)

MSI 从来都不是平台中立的。我假设您正在使用自定义操作来读取注册表值,因为 MSI 的 AppSearch/Reglocator 会将您限制到 WoWSys64 节点。之后,MSI 甚至会替换对程序文件的硬编码引用,作为应用程序兼容性方法的一部分(基本上微软假设您不知道自己在做什么,而他们知道您真正想要做什么)。

非官方 - 阅读此线程以找到我想出的解决此问题的方法。总结是我发现,如果您将 C:\Program Files\ 转换为短路径( C:\Progra~1 ),则 MSI 不够智能,无法弄清楚您所指的内容,因此它不会替换该值。

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

请注意,这是一个黑客行为,无法判断微软是否会在未来的版本中“修复它”。我能想到的唯一其他方法是您不使用快捷方式表,而是编写自定义操作来为您创建快捷方式。

如果您不想对抗 MSI,请考虑此解决方法。创建一个小型 64 位 EXE(是的,您可以将 64 位或 AnyCPU exe 部署到 Program Files x86 是 x86 MSI),充当 AutoCAD 的前端启动器。让它查询注册表并找到该文件,然后启动它,或者如果找不到该文件,则显示一条消息,说明 AutoCAD 不可用。

如果你这样做,你的安装就会变得更加干净。

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.

知你几分 2024-09-17 12:11:05

好的,我能够解决它:

问题是,64 位操作系统上的 32 位 MSI 正在将路径(在快捷方式表中)转换为 32 位等效路径,即我们的自定义操作 dll 正在从 64 位注册表项获取 AutoCAD 的路径,如下所示C:\Program Files\AutoCAD 2010\ 然后将此路径注入 MSI 的快捷方式表和目录表。但是当 MSI 编写快捷方式时,它将其转换为 C:\Program Files (x86)\AutoCAD 2010。

我们不能在 32 位 MSI 中拥有 64 位组件,但反之亦然是可能的,即我们64 位 MSI 中可以有 32 位组件。

然而,就我而言,我必须使用 64 位组件作为快捷方式,而其他组件将保留 32 位。

因此,我已将 32 位 MSI 转换为 64 位 MSI,并在软件包信息中添加 Plantform=x64 。并将组件声明为 Win64=Yes。

这解决了我的问题,现在我在快捷方式中获得了正确的路径。

因此,现在我有 2 个单独的安装程序,即分别对应 32 位和 64 位。

最好的问候

法鲁克

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文