[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

app.config & FileSystemWatcher

Jeff Mason

7/4/2008 3:50:00 PM

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
5 Answers

Jeff Winn

7/5/2008 2:26:00 PM

0

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@comcast.net> wrote in message
news:ihhs6490pvraea377lj6rvf5sq19ar5ims@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

Jeff Mason

7/6/2008 12:47:00 PM

0

On Sat, 5 Jul 2008 10:26:28 -0400, "Jeff Winn" <jwinn@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

sloan

7/9/2008 5:32:00 PM

0

You might find some useful hints here:

http://www.eggheadcafe.com/articles/20...
// 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@comcast.net> wrote in message
news:ihhs6490pvraea377lj6rvf5sq19ar5ims@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


Jeff Mason

7/10/2008 4:43:00 PM

0

On Wed, 9 Jul 2008 13:31:59 -0400, "sloan" <sloan@ipass.net> wrote:

>You might find some useful hints here:
>
>http://www.eggheadcafe.com/articles/20...

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

sloan

7/11/2008 8:15:00 PM

0

Good to know. Thanks for the followup.


"Jeff Mason" <je.mason@comcast.net> wrote in message
news:5lec74tvg2kdlm8jpk7ghd085liqhftd25@4ax.com...
> On Wed, 9 Jul 2008 13:31:59 -0400, "sloan" <sloan@ipass.net> wrote:
>
>>You might find some useful hints here:
>>
>>http://www.eggheadcafe.com/articles/20...
>
> 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