解决方案的 WiX 设置应该作为解决方案中的附加项目创建还是作为单独的解决方案创建？

问题描述

我有一个由 5 个项目（ASP.net Core Webservice 和 dll）组成的解决方案。对于这个解决方案，我想使用 WiX 创建一个设置。我正在使用 Visual Studio 2019。

该解决方案位于 Azure DevOps 中的 Git 存储库中。 已经有一个在每个拉取请求之后执行的自动构建过程。 我想扩展这个过程（或创建一个额外的过程），以便在构建后也能自动创建设置。

我应该将设置作为另一个项目添加到现有解决方案中，还是应该创建一个单独的解决方案？
我还没有在 AzureDevOps 中创建构建管道的任何经验，所以如果我现在选择“错误”变体，我担心以后可能会遇到问题。

这两种变体的优缺点是什么？
是否有关于何时使用哪个的最佳做法？

解决方法

解决方案是一个容器，用于组织一个或多个相关代码项目，例如类库项目和相应的测试项目。我们将查看项目的属性以及它可以包含的一些文件。我们还将创建从一个项目到另一个项目的引用。

因此，如果 WIX 项目与此解决方案中的其他项目相关，则将此设置作为另一个项目添加到您现有的解决方案中。

,

这是个人选择的问题，但经过 20 多年的安装开发，我更喜欢两种解决方案。原因如下：

优点：

1. 它有助于组织存储库以包含应用程序代码和安装程序代码。

2. 应用程序开发人员不必安装 WiX。项目不会在应用程序解决方案中加载失败。

3. 应用程序 sln 可以更新到较新版本的 Visual Studio，而无需等待安装工具集支持新版本。这在历史上一直是个问题。

4. 项目依赖性/项目构建顺序问题没有实际意义，因为所有应用程序项目都将在任何安装程序项目之前构建。

5. 应用程序开发人员不必担心安装程序开发人员会搞砸他们的项目。

6. 因为项目在不同的解决方案中，所以您不能使用项目引用，这可能是棘手和脆弱的。

7. 首先构建应用程序并使用构建后文件复制命令创建模型有助于定义安装程序的外观。

8. 安装项目经常需要使用甚至根本不使用 Visual Studio 或两者结合使用的项目中的文件。

缺点：

1. 分离代码可能会导致应用程序开发人员和安装开发人员之间出现“我们与他们”的情况。然而，这可以通过创建对角色和职责的清晰理解来缓解。没有什么能阻止开发者了解这两种解决方案并为之做出贡献。