views:

52

answers:

2

I am new to using .config files, having worked on apps that use .INI files and the registry until very recently. I am seeing a behavior in VS2008 that I would not anticipate, and wonder if it is the expected one.

When I configure the Working Directory setting in the VS2008 IDE for my Foo.exe application, I would have guessed that Foo.exe.config would get loaded from that Working Directory. It does not; it gets loaded from the ..\bin\Debug directory, even if I have a Foo.exe.config file in that Working Directory. If I examine the Environment.CurrentDirectory while the configuration is being applied by setting a breakpoint, I see that it is ..\bin\Debug. When I examine the Environment.CurrentDirectory after my main UI's Loaded event, it is set to the Working Directory I applied in the IDE.

Is this correct? (Why?)

A: 

The config is by default loaded from the same directory that the application resides in. In a debug environment this is \bin\Debug. However your project should be deploying that config for you if it is part of your project.

Russell Steen
By 'deploy', do you mean something like using Post-Build events to copy the app.config file to the appropriate directory? Thanks, Russell.
Phil Coveney
+1  A: 

Yes, this is the correct behavior that you are seeing. The executable looks for .config file in the same directory as the .exe first. Not sure where it looks after that, but if it finds it there it uses that one. I will do some more research and see if any other paths are searched by default.


See Here

By default, the application configuration file of the default appdomain (and other appdomains for v1.1 and later) is in the process exe’s directory and named the same as the process exe + ".config". This is true even if that exe is unmanaged. Also, note that a web.config file is an app.config - ASP.NET sets that as the config file for your appdomain.

To change the config file, set an AppDomainSetup.ConfigurationFile to the new location and pass that AppDomainSetup to your call to AppDomain.CreateDomain(). Then, run all of the code requiring that application config from within that new appdomain.

Note, though, that you won’t be able to choose the CLR version by setting the ConfigurationFile – at that point, a CLR will already be running, and there can only be one per process.

Application configuration files are per-appdomain. So, you can set a ‘dll config’ by using the method above, but that means that it will be used for the entire appdomain, and it only gets one.

David
Thanks, Dave, the link you attached is as much research as you need to do (and I aprreciate it). I just wanted to eliminate the possibility that I was doing something wrong out of lack of familiarity with .config files. If that's the rule, that's the rule. I see elsewhere that people are using Post-Build events to copy a source-controlled version of the app.config file to the appropriate directory during test and debug; I will use that approach. Thanks for your help.
Phil Coveney