我们正在为托管在 IIS8.5 中的 Web 应用程序使用 ASP.NET。 ASP.NET 使用 web.config 文件来存储所有应用程序和 IIS 相关的配置。每当我们为 Web 应用程序部署新版本的代码时，我们也会部署 web.config 文件。
最近，运营团队对此部署过程提出了担忧。他们说，如果有人更改了IIS中的某些设置，并且为此更新了web.config，则开发人员无法知道该更改，以便他们可以在代码库(版本控制系统)中更新web.config。因此，最终在下次部署时，web.config 更改将被旧的 web.config 覆盖。
可以采取两种可能的解决方案：
在- 每次部署代码之前，将 web.config 与服务器和代码库合并。
- 分离不同配置文件中的应用程序配置和 IIS 配置。
我的问题是，在 ASP.NET 中解决此类问题的最佳实践是什么？
IIS 7+引入了其分布式配置，允许IIS和.NET配置存在于Site/App/Directory web.config文件中。 造成这种情况的主要原因之一如下：在 IIS 6 中，每当应用程序团队需要部署其应用程序并更改"默认文档"等设置时，他们都需要 IIS 团队参与，因为"默认文档"是 IIS 配置设置。 您可能会争辩说，特定应用程序的默认文档设置不是 IIS 配置，而是应用程序配置。 因此，应用程序团队应拥有该配置设置，并将其部署为应用程序的一部分。
有关 IIS7+ 配置系统的更多信息：管理员可以配置允许在 Web.config 文件中设置的设置。 例如，默认情况下，可以在 Web.config 文件中设置"默认文档"，而 Windows 身份验证等身份验证设置则不能。 实现实际上可能会变得复杂，但如果你想阅读它，你可以在这里看到它：https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/how-to-use-locking-in-iis-configuration。
最终，最佳做法是让 IIS 管理员配置他们希望应用程序团队管理的设置(通过将这些设置委派给 Web.config)，然后不接触它们。 换句话说，如果需要更新默认文档，则应用程序团队负责发布新的 web.config 文件。 如果 IIS 团队决定要管理默认文档，则需要锁定 IIS 配置系统以禁止在 web.config 文件中管理默认文档。