C# 在asp.net 5.0中，我们应该如何管理每个站点的参数？

我们正在尝试将一组相当复杂的web应用程序从.NET 4.5迁移到.NET 5.0，托管在IIS中

我们需要解决的一个问题是如何在部署期间管理每个环境的配置

在.NET4.5中，我们使用web部署包。生产团队已经为许多客户和环境提供了数百个xxx.SetParameters.xml文件

在开发和测试中，我们使用appsettings.%ASPNETCORE_ENVIRONMENT%.json，但这对我们的生产部署不起作用

生产团队希望继续使用包含xxx.Parameters.xml和xxx.SetParameters.xml文件的web部署包，这样他们就不必在某些新机制中重新构建它们

我们可以告诉他们必须改变，如果他们真的必须改变的话

在asp.net 5.0中，通常如何管理每个环境的配置设置

---

一些补充澄清

在我们现有的流程中，构建生成一个部署包

然后，部署到特定环境将获取该包和定义该特定环境配置的文件，并创建一个站点并应用该配置

目前正在使用msdeploy，但这并不重要。重要的是，每个环境的配置文件都保存在单独的存储库中，而不是与源代码一起存储

我们也不希望他们这样

---

每个环境配置文件的更改历史记录与用于创建部署包的源代码的更改历史记录完全无关。

“但这对我们的生产部署不起作用”——为什么不？也就是说，如果您想坚持使用XML，您可以使用一种方法。但是基于IIS的应用程序配置不能与ASP.NET核心一起使用。为什么不能？因为我们有数百个环境，有些是本地环境，有些是非本地环境，而对于prod团队来说，每次发生更改时都必须返回到开发团队以推动提交，这是不可接受的开销。appsettings.json文件中的所有设置。。。这些文件是按一个文件在另一个文件之上的顺序应用的。既然你已经自动化了如何提取这些文件。。。选择适当的生产文件的逻辑非常简单，只需将该文件重命名为appsettings.json，而无需任何环境（即第一个加载的文件）。存储库中不需要特定于环境的文件。因此，是的，您可以拥有数百个

appsettings.envname.json

文件（而不是XML文件），并以与以前几乎相同的方式应用。然后只使用一个环境名称（例如“Production”，因为这是默认环境），将您的文件命名为

appsettings.Production.json

，并严格执行此操作。