WiX、TeamCity和NuGet集成指南

Question

这可能会被标记为“不是一个真正的问题”，但我对NuGet是否适合WiX部署感到非常困惑(您可以根据最后的问题来猜测)。

现状

我们的TeamCity构建为我们的WinForms产品创建了WiX刻录(3.6)安装程序，这些产品被发送到我们的服务器。应用程序调用我们的web服务，以确定是否有更晚的版本，它有权，如果是的话，下载它在后台，所以，这是准备好安装时，下次应用程序启动。

新需求

我们有一些新的功能，通过一个c#包包含在我们的NuGet解决方案中。由于包中的特定功能，我们90%的客户端安装都不需要这个包，所以可能需要它自己的msi。问题中的NuGet包不是我们的，它驻留在我们的供应商服务器上，需要身份验证才能获得。

不知何故，我对NuGet的世界是陌生的，我的头脑无法适应WiX.

• 我是否将NuGet包作为CI构建的一部分，并将其包含在WiX安装程序中，这样就不会从供应商站点下载它(这将解决身份验证问题)吗？
• 我是否创建了一个新的MSI，其中包括Nuget包中的组件，但实际上根本不使用NuGet进行最终的客户端部署？(这将解决许多问题，但每次更新NuGet包时都可能需要工作，而且感觉不对！)
• 我是否创建了一个作为刻录安装的一部分单独下载的无头MSI包？客户端将无法输入所需的身份验证，因为它们将不具有身份验证。
• 如果NuGet包是在安装期间安装的，并且总是获得最新可用的，那么如果供应商更新了NuGet包，我们的安装可能会在晚些时候失败，而供应商会以某种方式破坏我们的安装。如果NuGet包是在客户机上下载的，有什么方法可以绕过这个问题吗？

非常感谢，困惑！

Answer 1

处理第三方软件包最直接的方法是为最终用户使用它们的可再发行安装程序(例如，使用Burn)。据推测，它们已经处理了目标平台所需的所有问题，今后将继续这样做，甚至可能已经提供了一个更新机制。对于来自微软的许多组件，如.NET框架和VC运行时，这一点肯定是正确的。

Nuget是为开发人员准备的。它下载依赖项，将它们添加，并可能将源代码、配置元素等添加到项目中。因此，它通常不用于向最终用户分发库。如果库没有为最终用户提供自己的安装程序，您可以(如果许可证允许的话)将其包含在产品的安装程序中，或者按照您的建议单独安装。

与往常一样，它的基础是应用程序将如何处理不同版本的库以及如何在运行时找到它们。这可以非常简单，但它本身就是一个完全不同的话题。您必须在安装、设计和构建过程中考虑这一点。