app.config & FileSystemWatcher
in [Framework]
|
From: Jeff Mason on 4 Jul 2008 11:49 I'm trying to write some code that will detect changes in a Windows Service app's ..config file and reflect the modified appSetting entry in my code. We have a windows Service we've written and every once in a while we need to modify a setting in its .config file. Right now we restart the service whenever the config entry changes. We'd like to have the .config update be recognized automatically. It's easy enough to hang a FileSystemWatcher off the application's .config file to detect a change. In the event handler I am executing: ConfigurationManager.RefreshSection("appSettings") but this seems to have no effect. The value returned by subsequently referencing ConfigurationManager.AppSettings(<somekey>) is the original value, not the one just changed. The help for RefreshSection claims: "Refreshes the named section so the next time it is retrieved it will be re-read from disk." but this doesn't appear to work. What am I doing wrong? Thanks for any help. - Jeff -- Jeff
From: Jeff Winn on 5 Jul 2008 10:26 Are you sure the FileSystemWatcher instance you're using is raising the event as expected? I've used them for this same scenario in the past for services I've written, and found that the events I expected to be raised depended upon which application was editing the config file. IE: Notepad fires the Changed event when editing the file, while Visual Studio uses a temporary file and then deletes and recreates the file when saved which won't fire the Changed event. You might want to start looking at adding event handlers for all the events, and test them individually to see which events are being raised and which ones aren't. More than likely that's the problem you're having. "Jeff Mason" <je.mason(a)comcast.net> wrote in message news:ihhs6490pvraea377lj6rvf5sq19ar5ims(a)4ax.com... > I'm trying to write some code that will detect changes in a Windows > Service app's > .config file and reflect the modified appSetting entry in my code. > > We have a windows Service we've written and every once in a while we need > to modify a > setting in its .config file. Right now we restart the service whenever > the config > entry changes. > > We'd like to have the .config update be recognized automatically. > > It's easy enough to hang a FileSystemWatcher off the application's .config > file to > detect a change. In the event handler I am executing: > > ConfigurationManager.RefreshSection("appSettings") > > but this seems to have no effect. The value returned by subsequently > referencing > ConfigurationManager.AppSettings(<somekey>) is the original value, not the > one just > changed. > > The help for RefreshSection claims: "Refreshes the named section so the > next time it > is retrieved it will be re-read from disk." but this doesn't appear to > work. > > What am I doing wrong? > > Thanks for any help. > > - Jeff > > -- Jeff
From: Jeff Mason on 6 Jul 2008 08:47 On Sat, 5 Jul 2008 10:26:28 -0400, "Jeff Winn" <jwinn(a)nospam.com> wrote: >Are you sure the FileSystemWatcher instance you're using is raising the >event as expected? I've used them for this same scenario in the past for >services I've written, and found that the events I expected to be raised >depended upon which application was editing the config file. IE: Notepad >fires the Changed event when editing the file, while Visual Studio uses a >temporary file and then deletes and recreates the file when saved which >won't fire the Changed event. > >You might want to start looking at adding event handlers for all the events, >and test them individually to see which events are being raised and which >ones aren't. More than likely that's the problem you're having. > I am positive that the correct events are being raised. My event handler is set to handle the delete, changed, and created events, and that event properly fires when the .config file is modified. I temporarily placed a message box in the event handler to see each event and the type of change and it seems like the events are working correctly. I do see that the event can sometimes fire multiple times when using notepad for example. A little strange maybe, but since all I'm trying to to is execute a RefeshSection, executing it more than once presumably can't hurt. -- Jeff
From: sloan on 9 Jul 2008 13:31 You might find some useful hints here: http://www.eggheadcafe.com/articles/20041204.asp // nasty bug in FileSystemWatcher fires twice (in about 4 ms) on changed file. This is a workaround... I'm not sure if it will help you, but sometimes its nice to see what someone else tried. "Jeff Mason" <je.mason(a)comcast.net> wrote in message news:ihhs6490pvraea377lj6rvf5sq19ar5ims(a)4ax.com... > I'm trying to write some code that will detect changes in a Windows > Service app's > .config file and reflect the modified appSetting entry in my code. > > We have a windows Service we've written and every once in a while we need > to modify a > setting in its .config file. Right now we restart the service whenever > the config > entry changes. > > We'd like to have the .config update be recognized automatically. > > It's easy enough to hang a FileSystemWatcher off the application's .config > file to > detect a change. In the event handler I am executing: > > ConfigurationManager.RefreshSection("appSettings") > > but this seems to have no effect. The value returned by subsequently > referencing > ConfigurationManager.AppSettings(<somekey>) is the original value, not the > one just > changed. > > The help for RefreshSection claims: "Refreshes the named section so the > next time it > is retrieved it will be re-read from disk." but this doesn't appear to > work. > > What am I doing wrong? > > Thanks for any help. > > - Jeff > > -- Jeff
From: Jeff Mason on 10 Jul 2008 12:42
On Wed, 9 Jul 2008 13:31:59 -0400, "sloan" <sloan(a)ipass.net> wrote: >You might find some useful hints here: > >http://www.eggheadcafe.com/articles/20041204.asp Thank you. I think I have a handle on what may be going on. The problem I'm having may be related to my running/debugging within the VS2005 environment. There are these <app>.vshost.* files that may be getting in the way. It sort of looks like the caching of config data is from the <app>.vshost.exe.config file and not the <app>.exe.config as it normally is in a "stand-alone" mode. I found that running my tests in a stand-alone environment works as I expected. Running inside VS2005 will work if I edit the <app>.vshost.exe.config and watch for changes on that file. Go figure. -- Jeff |