如何处理web.config内容的更新事件?如何检测 web.config 已更改?
如何处理web.config内容的更新事件?我的意思不是为了管理员目的(wmi 等),而是为了编程 - 我需要重新计算 Web 服务内的一些数据,以防配置参数发生更改。
WebConfigurationManager、ConfigurationManager、Configuration、ConfigurationSection、SectionInformation...中没有任何合适的事件,那么在哪里挖掘它们呢?
PS.net 3.5
How to handle web.config content's update event? I mean not for administrator purposes (wmi etc) but for programming - I need recalculate some data inside the web service in case configuration parameter has changed.
There are no any suitable events in the WebConfigurationManager, ConfigurationManager, Configuration, ConfigurationSection, SectionInformation... So where to dig for them?
P.S. .net 3.5
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以使用 System.IO.FileSystemWatcher 来监控对任何文件进行更改,包括 Web.config。当文件更改时它会引发一个事件。
You can use the System.IO.FileSystemWatcher to monitor changes on any file, including Web.config. It will raise an event when the file changes.
使用 System.IO.FileSystemWatcher 会带来两个架构问题(还有一个令人头疼的问题 - 安全性)。首先是在更改期间不可能锁定“整个配置”(静态和可重新计算),其次是在哪里托管监视线程的问题。
如果有框架事件就好了,不幸的是没有这样的事件。但我发现有一个舒适的解决方案 - 具有覆盖 PostDeserialize 方法的自定义配置部分。由于我不了解整个过程,所以存在一些风险,有很多神秘之处:在每个配置编辑上重新创建自定义部分实例两次,构造函数调用两次,Init 方法调用两次,当 PostDeserialize 时 - 仅调用一次 - 所以一切都是对我们来说没问题 - 但谁知道我们在生产中会遇到什么......
Using System.IO.FileSystemWatcher brings two architecture problems (and one headache - security). First is impossibility to lock "whole configuration" (static and recalculable) during changes and second is the question where to hoste the monitoring thread.
It would be nice to have framework event, unfortunalty there are no such event. But I found that there is comfortable solution - have custom config section with overridden PostDeserialize method. There is some risk since I don't understand whole process, there is a lot of mystic: custom section instance is recreated on each config edit TWICE, constructor called twice, Init method called twice, when PostDeserialize - called only once - so all is ok for us - but who knows what we can meet in production...