Ureader.com  
Microsoft software help and Community
   home   |   control panel login   |   archive   |  
 
DotNet
acad.assignment.mngr
academic
adonet
aspnet
aspnet.announcements
aspnet.build.controls
aspnet.caching
aspnet.datagridcontrol
aspnet.mobile
aspnet.security
aspnet.webcontrols
aspnet.webservices
clr
compactframework
component_services
datatools
distributed_apps
drawing
faqs
framework
framework.wmi
general
internationalization
interop
languages.csharp
languages.jscript
languages.vb
languages.vb.controls
languages.vb.data
languages.vb.upgrade
languages.vc
languages.vc.libraries
myservices
odbcnet
performance
remoting
scripting
sdk
security
setup
vjsharp
vsa
webservi.enhancements
webservices
windowsforms
windowsforms.controls
winforms.databinding
winforms.designtime
xml
  
 
date: Fri, 04 Jul 2008 11:49:30 -0400,    group: microsoft.public.dotnet.framework        back       


app.config & FileSystemWatcher   
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
date: Fri, 04 Jul 2008 11:49:30 -0400   author:   Jeff Mason

Re: app.config & FileSystemWatcher   
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"  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
date: Sat, 5 Jul 2008 10:26:28 -0400   author:   Jeff Winn

Re: app.config & FileSystemWatcher   
On Sat, 5 Jul 2008 10:26:28 -0400, "Jeff Winn"  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
date: Sun, 06 Jul 2008 08:47:13 -0400   author:   Jeff Mason

Re: app.config & FileSystemWatcher   
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"  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
date: Wed, 9 Jul 2008 13:31:59 -0400   author:   sloan

Re: app.config & FileSystemWatcher   
On Wed, 9 Jul 2008 13:31:59 -0400, "sloan"  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
date: Thu, 10 Jul 2008 12:42:44 -0400   author:   Jeff Mason

Re: app.config & FileSystemWatcher   
Good to know.  Thanks for the followup.


"Jeff Mason"  wrote in message 
news:5lec74tvg2kdlm8jpk7ghd085liqhftd25@4ax.com...
> On Wed, 9 Jul 2008 13:31:59 -0400, "sloan"  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
date: Fri, 11 Jul 2008 16:15:17 -0400   author:   sloan

Google
 
Web ureader.com


    COPYRIGHT 2007, YARDI TECHNOLOGY LIMITED, ALL RIGHT RESERVE  |   contact us