我的所有Asp.Net网站都使用由XML文件驱动的单独配置系统，该系统负责构建整个站点中使用的大量对象;实际上，可以使用一系列超级IOC容器来解决从MVC站点的控制器到后端代码的数据服务和配置对象的任何问题。
XML构建了一堆动态方法，然后隐藏在工厂界面后面。加载和构建后，在App Domain回收之前，不会重建这些方法。
其中一个文件中的最小变化会对网站的功能产生深远的影响，因此通常可以将更新部署为简单的配置更改。这些文件可以出现在网站根目录及其中的任何子文件夹中 - 但不会出现在任何标准的Asp.Net文件夹（App_LocalResources等）中。
但是因为文件不使用Asp.Net/IIS认为是“重要”的扩展名（假设扩展名为.configfoo），如果我更改其中一个，我必须手动确保app域重新启动服务器上的任何一个：
a）触摸web.config以强制重启AppDomain;或
b）重新编译二进制文件
我想要做的是以某种方式告诉Asp.Net/IIS将这些文件包含在其监视中，并将它们视为重要和.config文件以及.dll中的.dll bin文件夹;如果其中任何一个更改，则触发应用程序域重新启动。
我尝试将文件放在bin\或App_LocalResources中，确实重新启动AppDomain - 这是个好消息，但是......我不喜欢bin\部署因为在开发过程中轻松更新文件的唯一方法是进行构建（除非您手动复制/粘贴），并且它也不符合这些文件的内容概念 - 这就是它们实际上是，并且需要从部署的角度来看待它。
同样，App_LocalResources（等）解决方案很棒，但从开发人员的角度来看并不自然 - 它是一个配置文件，因此应该能够放在与其他配置文件相同的位置（还有一个小问题，如果由于其上下文相关的Add New Item对话框而添加到此文件夹，VS似乎没有看到我已完成的项目模板。
最后它没有解决项目可能包含的其他自由格式文件夹的问题，这些文件夹可能包含.configfoo文件以及aspx / ascx / master / .config文件等。除非我强制这些文件夹全部是当然放在一个Asp.Net文件夹中，但没有人希望在App_LocalResources内找到一个页面！
失败 - 我记得在几年前看过一些使用FileSystemWatcher的代码，它根据自己的基于文件的规则在网站内触发AppDomain.Unload。我认为现在首选的方法是使用System.Web.Hosting.HostingEnvironment.InitiateShutdown。
这是我的最后一招，因为当我已经知道我想要的东西已经用于其他扩展时，我会犹豫不决。
那么可以向正在观看的人添加其他依赖文件吗？或者我将不得不自己动手？
任何建议，一如既往，非常感谢
答案 0 :(得分：2)
最后我自己动手了。
在网络应用程序启动时，我设置FileSystemWatcher监控AppDomain.BaseDirectory及其所有子文件夹，其过滤器为*.configfoo。
然后我连接到引发的四个事件（Created，Renamed，Deleted，Changed），然后调用System.Web.Hosting.HostingEnvironment.InitiateShutDown()（然后设置一个标志以防止它再次调用它，因为FileSystemWatcher通常会引发多个一个文件系统操作的事件。）
最后设置FileSystemWatcher.EnableRaisingEvents = true;并嘿presto。
答案 1 :(得分：0)
с）将配置文件放在其中一个受监控的目录中，例如App_LocalResources：monitored for creation, deletion, renaming, ACL changes, changes to the last-write time, and changes to the size。