在ASP.NET和IIS中部署时重写web配置文件

我们将ASP.NET用于承载在IIS 8.5中的web应用程序。ASP.NET使用web.config文件存储所有应用程序和IIS相关配置。每当我们为web应用程序部署新版本的代码时，我们也会部署web.config文件

最近，运营团队对此部署过程提出了担忧。他们说，如果有人在IIS中更改了某些设置，并且该web.config已经为此进行了更新，那么开发人员就无法知道该更改，从而可以在codebase（版本控制系统）中更新该web.config。因此，最终在下次部署时，web.config更改将被旧的web.config覆盖

可以采取两种可能的解决方案：

在每次部署代码之前，将web.config与服务器和代码库合并

在不同的配置文件中分离应用程序配置和IIS配置

---

我的问题是，解决ASP.NET中此类问题的最佳实践是什么？

IIS 7+引入了分布式配置，允许IIS以及.NET配置位于站点/App/Directory web.config文件中。其中一个主要原因如下：在IIS 6中，每当应用程序团队需要部署其应用程序并更改默认文档等设置时，他们都需要涉及的IIS团队，因为“默认文档”是IIS配置设置。您可能会争辩说，特定应用程序的默认文档设置不是IIS配置，而是应用程序配置。因此，应用程序团队应该拥有该配置设置，并将其作为应用程序的一部分进行部署

关于IIS7+配置系统的更多信息：管理员可以配置允许在Web.config文件中设置的设置。例如，默认情况下，“default Document”可以在Web.config文件中设置，而诸如Windows身份验证之类的身份验证设置则不能设置。实际上，实现可能会变得复杂，但如果您想了解它，可以在此处查看：

---

最终，最好的做法是IIS管理员配置他们希望应用程序团队管理的设置（通过将这些设置委托给Web.config），然后不碰它们。换句话说，如果需要更新默认文档，则应用程序团队负责发布新的web.config文件。如果IIS团队决定管理默认文档，然后，他们需要锁定IIS配置系统，以禁止在web.config文件中管理默认文档。

IIS 7+引入了其分布式配置，允许IIS以及.NET配置位于站点/App/目录web.config文件中。其中一个主要原因如下：在IIS 6中，每当应用程序团队需要部署其应用程序并更改默认文档等设置时，他们都需要涉及的IIS团队，因为“默认文档”是IIS配置设置。您可能会争辩说，特定应用程序的默认文档设置不是IIS配置，而是应用程序配置。因此，应用程序团队应该拥有该配置设置，并将其作为应用程序的一部分进行部署

关于IIS7+配置系统的更多信息：管理员可以配置允许在Web.config文件中设置的设置。例如，默认情况下，“default Document”可以在Web.config文件中设置，而诸如Windows身份验证之类的身份验证设置则不能设置。实际上，实现可能会变得复杂，但如果您想了解它，可以在此处查看：

---

最终，最好的做法是IIS管理员配置他们希望应用程序团队管理的设置（通过将这些设置委托给Web.config），然后不碰它们。换句话说，如果需要更新默认文档，则应用程序团队负责发布新的web.config文件。如果IIS团队决定要管理默认文档，则需要锁定IIS配置系统，以禁止在web.config文件中管理默认文档。

更重要的是了解您的操作团队希望执行的确切更改。他们需要的大多数更改都可以作为位置标记添加到

applicationHost.config

，以便不同的团队（开发人员/操作）管理不同的文件（

web.config

/

applicationHost.config

）。这就是您所说的“在不同的配置文件中解耦应用程序配置和IIS配置”吗？我认为应该逐案处理。至少在Microsoft文档中有“最佳实践”。更重要的是了解您的操作团队希望进行的具体更改。他们需要的大多数更改都可以作为位置标记添加到

applicationHost.config

，以便不同的团队（开发人员/操作）管理不同的文件（

web.config

/

applicationHost.config

）。这就是您所说的“在不同的配置文件中解耦应用程序配置和IIS配置”吗？我认为应该逐案处理。至少在Microsoft文档中有“最佳实践”。