安装后，C＃应用程序（使用WIX创建的安装程序）不会运行

经过几天的点击和试用后，我创建了一个简单解决方案的WIX安装程序，并按照几个教程，包括在安装结束时启动应用程序的选项，桌面上的图标和添加/删除程序列表中的应用程序快捷方式。 当它完全运行时，我为包含6个项目和SQLite数据库的原始项目复制了相同的过程。 但是现在当我安装安装程序时，单击桌面上已安装的图标无效。 它不会启动指定的exe。 请帮助我。

我应该分享wxs代码吗？

更新：以下是我的.wxs文件的大部分代码。 抱歉，我无法破译问题的根源，因此必须包含除标准顶级标签之外的所有代码。 此外，一旦发现问题，它可以成为其他Wix用户受益的参考。

                                                             WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed   

从Debug或Release文件夹运行时，Pihu.exe运行正常。 第一个屏幕独立于DB，因此不会出现问题。 我认为唯一的问题是解决方案是多项目（尽管所有依赖项目的dll也存在于Debug和Release文件夹中）

Answer 1

一旦您向问题添加更多详细信息，我将“演变”此答案。 我想避免太多评论。 是的， 请在您的问题中分享您的WiX源代码的核心，如果它是公开的并且不是太大而且您有一个上传它的位置 – 链接到它，甚至编译的MSI本身。

关于在线发布WiX源的快速说明：

在发布之前，请从WiX源中删除任何密码，数据库连接字符串，用户名，共享名称，IP地址或其他敏感数据 。 一个好的软件包不应该硬编码任何一个（它们应该是最终用户在安装时设置的参数），但是正如我们所知，有时硬编码的东西（通常来自你的开发盒）潜入源代码发展 – 给它一次性。 还请消除源代码中的硬编码GUID – 用PUT-GUID-HERE替换它们（不是那么重要，如果你不确定如何，我们会帮你做到这一点）。

初学者的一些问题：

• 您是否为产品代码，包装代码，组件GUID等使用了新的GUID？ 如果重新使用包代码或组件代码，可能会出现奇怪的结果。 重用相同的产品代码更容易检测，但这也可能导致问题。
• 您是否尝试直接从文件系统启动主EXE？ （检查问题是否与快捷方式有关）。
• 尝试启动应用程序时是否有任何错误消息？ 您是否也检查了事件日志（除了任何GUI错误）？ 该应用程序是否具有自己的自定义日志？ 如果是，请检查。
• 您是否在安装后扫描二进制文件中的依赖项？ 只是抛出一个链接，我写了最近的答案： 在Visual Studio 2017中为WPF应用程序创建MSI安装程序后，EXE什么都不做 （Dependencies.exe，procmon.exe，visual studio modules视图，几个选项……）。 您也可以尝试使用旧的Dependency Walker，即使它现在已经过时并且不能很好地处理Win32程序集依赖关系或Api-Sets。
• 您是否记录了MSI安装？ 如果没有，请这样做并检查是否有任何错误。 有关如何记录MSI安装，请参阅以下部分 。
  • 一旦你有了一个日志，就可以按照Rob Mensching的说明在日志文件中搜索“value 3” ，但在你的情况下，安装似乎已经成功完成，所以你需要查找警告并抑制错误。
  • 来自Windows Installer团队的Robert Macdonald的这篇文章强烈推荐作为MSI日志记录的实用外观： 如何解释Windows Installer日志 。
  • 全系列的msiexec.exe命令行选项 。 这是technet版本 。

记录您的MSI-Install

以下是如何记录您的安装：

 msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log" 

快速参数说明：

 /I = run regular installation sequence /QN = run completely silently /L*V "C:\My.log" = verbose logging at specified path 

如果这令人困惑，请尝试installsite.org的日志常见问题解答 – 如何为您的安装创建日志文件。

部署所有必需的文件（处理依赖项）

Wix没有“自动化” – 开箱即用 – 因为所有相关文件都是在构建时自动包含的（除非有一个我不知道的新function）。

您必须手动指定要使用MSI安装哪些文件，坦率地说，这是我认为的预期行为 – WiX为您提供的是安装程序的控制和灵活性 – 但有时需要处理起来有点繁琐。 但是，如果您尽可能轻松地做到这一点，您将会欣赏MSI的WiX源的灵活性和清晰度。

那么，你如何处理这个尽可能简单？ 我只是在Visual Studio中将您的构建类型设置为“Release”，然后进入Debug => Start Debugging以交互方式运行您的项目。 现在转到Debug => Windows => Modules并记下所有加载的文件（模块）。 然后将解决方案中加载的文件包含在WiX源中以部署到目标系统，并识别从计算机上其他位置加载的共享文件（系统文件）（例如GAC），并确定它们是否需要安装运行时在系统上。 您不得直接在WiX源中包含此类共享（或系统）文件，而应通过合并模块（用于安装共享运行时的机制）或执行安装运行时的单独setup.exe。

要将这些文件包含在WiX源中，只需将它们添加到WiX源中的相应目录即可。 最简单的forms：

上面的组件包含一个文件，该元素利用了WiX基于文件名本身默认大多数属性的能力。 组件ID和GUID是自动生成的 – 文件ID和名称也是如此。 我之前在这个答案中简要介绍过这个问题 – 也许有一个快速浏览： WIX中的guids语法？ 。

在您的源代码中内联，添加文件看起来像这样（使用上面直接链接答案中描述的这些最小组件元素）：

这只是我能想到的最简单的模型。 source属性是您需要指定的唯一必需属性。 我已将其设置为绝对路径以确保文件编译，但您应该使用WiX项目变量，就像在上面的源代码中一样。 请参阅使用项目引用和变量 。 在此期间，您还应该快速了解预处理器function 。

如果您按照说明正确地执行项目引用和变量，您应该能够获得类似于此的源代码（但是在深入研究之前可能会使用绝对路径编译WiX源代码 – 请注意， ConsoleApplication显然是编译应用程序二进制文件的Visual Studio项目的名称：

请放手一搏。 我现在没有时间测试编译，我自己使用不同的方案（我使用预处理器和语句来指定我复制了所有输出文件的发布文件夹 – 我没有引用文件直接来自Visual Studio输出文件夹）。

它看起来好像你已经使用BUILD变量执行此操作，但我通常使用基本构建输出路径，例如：

然后我的源元素变成这样的：

比我想象的更多细节和可能的意见，但我希望它可以帮助你解决问题。 一旦设置好，WiX源可以在您需要时进行调整。 灵活性非常出色。

使用heat.exe来“收获”文件夹

如果你只想添加几个文件，上面的方法应该没问题。 但是，如果要添加大量文件，则应使用WiX工具heat.exe 。 它允许您“收获”目录并使用所需的组件和文件元素生成WiX XML以安装相关文件。 这是heat.exe的官方文档 。

在最简单的forms，你可以使用这样的东西：

1. 打开命令提示符并导航到要包含在MSI中的文件夹结构。
2. 尝试像heat.exe dir . -sfrag -out HeatTest.wxs这样的东西heat.exe dir . -sfrag -out HeatTest.wxs heat.exe dir . -sfrag -out HeatTest.wxs生成WiX XML文件HeatTest.wxs 。 它现在将包含所需的XML，用于从您导航到的文件夹和下面的文件夹中安装有问题的文件（ .表示当前文件夹）。
3. 我更喜欢用空字符串搜索和替换Guid="PUT-GUID-HERE" ，因为可以自动生成GUID。 我没有看到允许创建“Minimal WiX XML”的转换 – 换句话说只有必需的属性。 我想你也可以省略目录ID。
4. 我还想用定义的值替换源属性默认路径，例如RELEASEFOLDER。 像这样的东西： heat.exe dir . -sfrag -var var.RELEASEFOLDER -out HeatTest.wxs heat.exe dir . -sfrag -var var.RELEASEFOLDER -out HeatTest.wxs 。 试试看。 现在Source属性变为： Source="$(var.RELEASEFOLDER)\src\Burn\Frost\Frost.sln"而不是Source="SourceDir\src\Burn\Frost\Frost.sln" 。

通过一些练习，使用此heat.exe工具创建MSI的基本安装结构非常快速，并对生成的源进行一些手动清理。 我非常喜欢创建繁琐的“文件密集型”软件包，例如IIS安装程序，这些软件包可能包含数千个无法尝试手动创建WiX XML的文件。