ConfigSource .NET configuration files outside the application directory folder

I have two applications - one is a console application and the other is an ASP.NET application. Both of them must know the same application settings and connectionStrings. Therefore, ideally, I would like to use the configSource property of the app.config / web.config files to indicate a central location. for example

<connectionStrings configSource="D:\connectionStrings.config"/> <appSettings configSource="D:\appSettings.config"/> 

Something does not work with an error:

Invalid configSource attribute. Invalid configSource 'D: \ appSettings.config parameter. It should reference the file in the same directory or subdirectory as the configuration file.

Is there anyway to use appSettings / connectionStrings configuration managers and get values ​​from an external location?
I am pleased to need to add code to do this, but I do not want to replace the entire configuration system.

+73
configuration
Feb 20 '09 at 10:54
source share
9 answers

Another solution is to simply add the configuration file to all your projects as a link instead of actually copying the file to your projects. Then set the “Build action” of the file to “Content” and “Copy to output directory” to “Copy if new”, and when you compile the project, you will have the file in the output directory.

To add a file as a link, select Add As Link in the Add Existing Element dialog box.

+85
Mar 28 '09 at 22:56
source share

In appSettings you can use file = instead of configSource =

+28
Dec 02 '09 at 17:01
source share

It seems that way it is. configSource must be in the same folder or deeper.

You could, although I'm not sure you should use the NTFS hard link. [crazy grin]

+16
Feb 20 '09 at 11:03
source share

You can load the configuration from an arbitrary location, but it will not be available through the static properties of the ConfigurationManager:

 Configuration myConfig = ConfigurationManager.OpenExeConfiguration(path) 

(There is an overload that allows you to specify multi-user files to support the default hierarchy / user roaming / user).

The loss of static properties means that all code must be aware of a different configuration.

+7
Feb 20 '09 at 11:01
source share

Visual studio 2015

If you are having this problem with Web.Config, then the accepted answer is correct, but just for extension, as it gave me a palm face:

When you add the .config file to your project using the “Add as link” link, and then set the copy property to the “Copy if new” or “Always copy” links, the physical file will be copied to the / bin folder,

Thus, if you have a configuration section defined in Web.Config as follows:

  <section name="mySpecialConfig" type="System.Configuration.AppSettingsSection" requirePermission="false" /> 

then you must define the appropriate configuration item as follows:

  <mySpecialConfig configSource="bin\MySpecialConfig.config"> </mySpecialConfig> 

so configSource points to a physical bin \ MySpecialConfig.config file not a link . Also note that the path is a relative physical path.

This may seem ridiculous, but if you haven’t done so yet, while the physical file is not already in the \ bin folder, so that it does not click right away.

+3
Jul 16 '16 at 7:25
source share

You can set both settings in machine.config , and then they are available for all your applications on the server.

+2
Feb 20 '09 at 11:01
source share

The solution I found best was to put the “shared” configuration files in the central files, and then use the pre-build event in Visual Studio to copy them to the relative folder of each project that needed it.

+2
Mar 11 '09 at 11:02
source share

I had a pretty big problem with this problem, but I found a good solution for it: test run with external configuration

(You can direct a test run to copy files and directories to the test run directory by editing the .testrunconfig file.)

Despite the fact that a project like unit test can get configuration settings from its own app.config, but cannot load related configuration files, like a regular app.config, it seems to me that something is not clear. I would call it a mistake because you expected the test app.config project to behave the same as the app.config application, but it is not.

+2
Jul 27 '10 at 12:43 on
source share

In the case of connection strings, you can indeed specify a shared file. If the shared file is located on a UNC network, it requires administrative privileges on the computer on which the application will be hosted.

Decision. In your web.config, use configSource to point to the local configuration file. Due to .Net restrictions, this should be at or below the root of the configuration file. I just point to the file in the application folder itself:

 <connectionStrings configSource="ConnectionStrings.config" /> 

In a shared location accessible to the application pool user, add a configuration file containing shared connection strings. This file should not contain any xml, except for the connectionStrings section itself. The general ConnectionStrings.config file is as follows:

 <connectionStrings> <clear/> <add name="connString1" connectionString="connString1 info goes here"/> <add name="connString2" connectionString="connString2 info goes here"/> </connectionStrings> 

Now the trick. Create a Windows symbolic link in the application folder, pointing to an external shared configuration file. To do this, you will need administrator rights:

 mklink ConnectionStrings.config \\someServer\someShare\someFolder\ConnectionStrings.config 

We just outsmarted .Net. The configuration system will use the configSource parameter to search for connection strings in the local ConnectionStrings.config file. A symbolic link looks like a file in .Net, and a symbolic link resolves to a shared configuration file.

Cautions. Changes to the shared file do not start restarting the application in .Net. In the case of IIS, the website or application pool will need to be restarted manually.

Due to the need for administrative privileges to create a symbolic link, this approach may not work for everyone. There are two related alternatives that can work if the shared file is on the same logical drive - hard links and connections. See this discussion and this discussion for more details.

+2
Aug 29 '16 at 20:21
source share



All Articles