0

设想：

  • 我们有一个 .vdproj 安装程序（实际上我们有很多，带有合并模块，但让我们保持简单）。
  • 我们有一个新版本的产品。
  • 我更改了产品代码、升级代码和版本，重新引导了 AssemblyInfos 和任何 COM 接口，并更改了默认安装位置。

一切看起来都很好，程序并排工作。但是，如果同时安装了两个版本，则在卸载时不会删除程序菜单和桌面快捷方式，并抱怨由于未删除组件而无法删除它们。（引用计数的味道嗯？）。

虽然这是一个外观问题，但我决定看一看，在 Orca 中我注意到文件的 ComponentIds 是相同的。

看起来这些是基于 的哈希[TARGETDIR]\myfile，而不是实际扩展的TARGETDIR.

例如 myTARGETDIR在安装时实际上是不同的，c:\program files\myCompany\v1.0\myfile并且c:\program files\myCompany\v2.0\myfile

但是对于安装程序项目，我认为它是基于它的 hash off TARGETDIR\filename。

我发现

  • 重命名输出文件以myfile2生成不同的 ComponentId
  • TARGETDIR或者 - 在安装中创建调用的子文件夹v2.0会产生不同的 ComponentId。但我不确定这会产生什么影响。

我是否正确解释了正在发生的事情，这是我唯一的解决方法吗？将顶级文件夹共享为TARGETDIR.

微软一年多没有更新这个 VS2015 组件，也没有开源它，我假设他们很高兴它死了，我应该搬到 Wix 吗？

更新 这似乎只是合并模块的问题，而不是顶级安装程序。

4

1 回答 1

1

正如您所发现的，Visual Studio 不会公开组件 ID。如果组件 ID 存在其他问题（或者 WiX 支持 VS 不支持的东西），那么可以，迁移到 WiX。但是，在您可能只有一个组件 ID 的情况下，最简单的解决方案是执行构建后步骤来更改该组件 ID。使用 Windows Installer SQL 和 WiRunSql.vbs 等脚本（来自 Windows SDK），您只需更改 id。

https://msdn.microsoft.com/en-us/library/windows/desktop/aa372021(v=vs.85).aspx

微软曾经尝试过弃用安装程序项目，但它们被大众需求带回来了，因此在任何情况下迁移到其他项目的计划都可能是一个好主意。

于 2016-11-29T18:31:29.807 回答