views:

241

answers:

4

I am currently updating a few settings in a rather large *.exe.config file via the *.exe executable by using XLinq to navigate the directories and read / write the values. The problem with updating this way is that changes only take effect after restarting the executable, but I would like the changes to take effect instantaneously. Is there a way to tell the executable to reload the *.exe.config file after I make the changes?

All help is appreciated and thanks in advance!

Exoskeleton for app.config

<configuration>
  <system.serviceModel>
    <!-- stuff... -->
    <client>
      <!-- this is the section I changed and want to have updated -->
    </client>
  </system.serviceModel>
</configuration>

EDIT: One of the reasons that I know so little on this subject is that I didn't create the app.config - it's auto-generated by somebody else's code. The reason that I have to change it and have the changes take effect in the application is that another part of the code (which I have no access to) calls on the config file to get its data, but if I don't reload the section then the old settings will be used, which won't work in this application.

EDIT2: If I can't change this dynamically, how do I change the code so that it can be done dynamically? Best answer gets the bounty...

+1  A: 

Settings with scope "User" can be easily stored and retrieved while the Application is running. If your settings are of scope "Application" I'm afraid you cannot modify and reload them without restarting your application. You'll need to roll your own configuration solution then.

Johannes Rudolph
How can I figure out the scope of my settings?
adam_0
If it's in the application.exe.config file, then it's application-scoped. If the config file is in your user profile/AppData/Local folder, then it is user-scoped. And judging from what I see in your code snippet, you're not going to be able to reload dynamically. .NET Configuration just can't do that at this time.You may have luck using configSource attribute.
Eric Falsken
@Eric: Exactly. This issue is well-known and documented appropriately on MSDN.
Johannes Rudolph
What's the configSource attribute? Also, if I were to put these configurations in a new file, how would I read/write to them? Best answer gets the bounty...
adam_0
+1  A: 

There are 2 parts to making this work. 1) Updating the correct config file, and 2) forcing .net to reload the changes.

1) When a .net process starts, it will copy the existing .config to the vshost.exe.config file. If you update the original config file after the process has started, you will not see it in the vshost.config until you restart the process. So to make this work at runtime, you need to update the vshost.exe.config, not the exe.config file.

2) To force .net to reload the settings, you need to tell the configuration manager that the settings changed. You can do this with the ConfigurationManager.RefreshSection().

There is some more information and a couple code examples at: http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/3c365fdb-563e-4b0a-a4b4-df684c2dd908/

Mike
James Curran
This method works the first time I change the file, but subsequent changes don't take effect. Any idea why this is happening?
adam_0
This isn't the "correct" answer yet, as I haven't gotten it to work properly, but it was the closest so I awarded the bounty here.
adam_0
+1  A: 

Basically, Microsoft designed it this way (having the configuration read at start up and not again), specifically to discourage you from trying this, because the *.config file live in the C:\Program Files folder, and that should not be writable by a non-Administrator.

James Curran
+1  A: 
var client = 
 System.ServiceModel.ChannelFactory<ISampleService>(
  System.ServiceModel.Channels.Binding binding, 
  System.ServiceModel.EndpointAddress remoteAddress)

you can connect to a service also programmatically, and give the WCF directly the config needed.

with using this, you do not need the wcf config in the exe any more.

http://msdn.microsoft.com/de-de/library/ms576132.aspx

cRichter
Link worked great when I switched it to en-us instead of de-de :) I will see if I can get a look at the code that makes the client and try to implement your suggestion.
adam_0