解决方案的 WiX 设置应该创建为解决方案中的附加项目还是单独的解决方案？
Should a WiX setup for a Solution be created as an additional project in the Solution or as a separate Solution?
我有一个包含 5 个项目（ASP.net 核心 Web 服务和 dll）的解决方案。对于此解决方案，我想使用 WiX 创建一个设置。我正在 Visual Studio 2019 年工作。
该解决方案位于 Azure DevOps 的 Git 存储库中。
已经有一个在每个拉取请求之后执行的自动构建过程。
我想扩展这个过程（或创建一个额外的过程）以便在构建后自动创建设置。
我应该将设置作为另一个项目添加到现有解决方案中，还是应该创建一个单独的解决方案？
我还没有在 AzureDevOps 中创建构建管道的任何经验，所以如果我现在选择“错误的”变体，我担心以后可能 运行 会遇到问题。
两种变体的优缺点是什么？
是否有关于何时使用哪个的最佳实践？
解决方案是一个容器，用于组织一个或多个相关代码项目，例如 class 库项目和相应的测试项目。我们将查看项目的属性以及它可以包含的一些文件。我们还将创建从一个项目到另一个项目的引用。
因此，如果 WIX 项目与此解决方案中的其他项目相关，则将此设置作为另一个项目添加到您现有的解决方案中。
这是个人选择的问题，但经过 20 多年的安装开发，我更喜欢两种解决方案。原因是：
优点：
它有助于组织存储库以包含应用程序代码和安装程序代码。
应用程序开发人员不必安装 WiX。项目不会在应用程序解决方案中加载失败。
无需等待安装工具集支持新版本，即可将应用程序sln更新至更新版本Visual Studio。这在历史上一直是个问题。
项目依赖/项目构建顺序问题没有实际意义，因为所有应用程序项目都将在任何安装程序项目之前构建。
应用程序开发人员不必担心安装程序开发人员搞砸他们的项目。
因为项目在不同的解决方案中，所以你不能使用项目引用，这可能很棘手和脆弱。
首先构建应用程序并使用构建后文件复制命令创建模型有助于定义安装程序的外观。
安装项目经常需要使用甚至可能根本不使用 visual studio 或两者兼而有之的项目中的文件。
缺点：
- 分离代码会导致应用程序开发人员和安装开发人员之间出现“我们对他们”的局面。但是，可以通过清楚地了解角色和职责来缓解这种情况。没有什么能阻止开发人员了解这两种解决方案并为之做出贡献。
我有一个包含 5 个项目（ASP.net 核心 Web 服务和 dll）的解决方案。对于此解决方案，我想使用 WiX 创建一个设置。我正在 Visual Studio 2019 年工作。
该解决方案位于 Azure DevOps 的 Git 存储库中。 已经有一个在每个拉取请求之后执行的自动构建过程。 我想扩展这个过程（或创建一个额外的过程）以便在构建后自动创建设置。
我应该将设置作为另一个项目添加到现有解决方案中，还是应该创建一个单独的解决方案？
我还没有在 AzureDevOps 中创建构建管道的任何经验，所以如果我现在选择“错误的”变体，我担心以后可能 运行 会遇到问题。
两种变体的优缺点是什么？
是否有关于何时使用哪个的最佳实践？
解决方案是一个容器，用于组织一个或多个相关代码项目，例如 class 库项目和相应的测试项目。我们将查看项目的属性以及它可以包含的一些文件。我们还将创建从一个项目到另一个项目的引用。
因此，如果 WIX 项目与此解决方案中的其他项目相关，则将此设置作为另一个项目添加到您现有的解决方案中。
这是个人选择的问题，但经过 20 多年的安装开发，我更喜欢两种解决方案。原因是：
优点：
它有助于组织存储库以包含应用程序代码和安装程序代码。
应用程序开发人员不必安装 WiX。项目不会在应用程序解决方案中加载失败。
无需等待安装工具集支持新版本，即可将应用程序sln更新至更新版本Visual Studio。这在历史上一直是个问题。
项目依赖/项目构建顺序问题没有实际意义，因为所有应用程序项目都将在任何安装程序项目之前构建。
应用程序开发人员不必担心安装程序开发人员搞砸他们的项目。
因为项目在不同的解决方案中，所以你不能使用项目引用，这可能很棘手和脆弱。
首先构建应用程序并使用构建后文件复制命令创建模型有助于定义安装程序的外观。
安装项目经常需要使用甚至可能根本不使用 visual studio 或两者兼而有之的项目中的文件。
缺点：
- 分离代码会导致应用程序开发人员和安装开发人员之间出现“我们对他们”的局面。但是，可以通过清楚地了解角色和职责来缓解这种情况。没有什么能阻止开发人员了解这两种解决方案并为之做出贡献。