微软在 VS 2012 中令人烦恼的 vdproj 安装项目倾销导致人们尝试使用 VS2012 中内置的 Installshield LE。可悲的是，它创建的安装程序不能以任何方式使用 64 位形状或形式。
因此，例如单击已安装 Office 2010 复选框仅是 32 位 Office 的先决条件。它无法检测到 64 位。
在对 Installshield 进行了大量无脑探索之后，底线是：1）您需要 Professional 或 Premiere 版本才能处理 64 位。2）您需要编辑他们提供的条件，以制作一个复合条件，将您感兴趣的所有 Office 指南合并在一起，因为它只检查开箱即用的众多指南之一。这详细说明了 GUIDS 的结构：http: //support.microsoft.com/kb/2186281 ?wa=wsignin1.0 。我发现在 VM 中安装各种版本然后使用 regedit 查看 GUID 最终是什么很有帮助。
这篇文章是为了让人们可以通过 Google 搜索实际发现这一点，而不是隐藏在付费专区/私人支持网站后面。
更新 13 年 10 月的 AlBear
有一个用于 VS2012/13 的 installshield LE 测试版 要构建 x64 安装包，请查看帮助文件查找“64 位”。
InstallShiel LE 识别 x64 目标的方式是将 [INSTALLDIR] 属性定义为 64 位文件夹之一，或者将至少一个设置组件定义为 64 位。这适用于我构建了一个 Excel 2013 Add，它在启动时加载并且工作正常。
要使 VSTO 工作的先决条件：您需要更改文件大小和散列 看起来 Microsoft 文章“部署 Office 解决方案 vsto 2013”中的建议已过时，并且推荐的 XML 代码具有错误的文件大小和散列。修起来也不是太难。然而，我认为微软不幸正在经历一段危机时期，而未能提供合理的支持是未知领域.......干杯
InstallShield 和 WiX 就像使用 VB.NET 的 Visual Studio 和使用 C# 的 SharpDevelop。就像这些工具都使用 IL 代码创建 EXE 和 DLL，但使用不同的语言提供程序一样，
InstallShield 和 WiX 都使用不同的语言创建 Windows Installer 数据库。就像 VB EXE 可以使用 C# DLL 一样，InstallShield MSI 可以使用 WiX Merge Modules。这为您提供了两全其美的体验。
要了解的是 VSTO 插件安装程序不是 64 位 MSI，它是 32 位 MSI，它部署了带有 32 位或 64 位 Office 注册表项的 AnyCPU DLL。最终，Office 的位数决定了 AddIn 的位数。
我有一个用于十几个客户的模板。它使用 InstallShield Limited Edition 和 Preq Bootstrapper 来放置所有依赖项并使用由 WiX 和 IsWiX (CodePlex) 编写的合并模块。否则 ISLE 只是 UI 的容器，它是一个功能。
合并模块负责所有的依赖检测、门控逻辑、放置文件、安装证书、设置注册表值等等。
可以在以下位置找到更多详细信息：
显然这里引用的小字应该是一个线索：InstallShield Limited Edition Support 64 bit Installer？
Installshield 中当前的 Office 先决条件也具有误导性。它应该是“Office 2010 Home & Professional 32 位”。
也许他们打算随着时间的推移对其进行升级以使其更加全面，或者每个人都必须经历同样的麻烦来解决他们关心的一些案例。支持人员声称对于所有版本、位数、版本等组合的 GUIDS 太多。
家庭和学生、家庭和专业、专业、Office 2010 Professional Plus 许可证 32 位、64 位、其中的语言、Service Pack 等。根据您关心的 GUIDS 数量的不同，GUIDS 的数量相当大。