2

I have developed a small windows service which performs few database operations. I have to give an option to the user to change server name on post-deploy. if user changes in app.config it doesn't affect the service, it is still reading connection strings from AppName.exe.config.

Here what I have tried.

<connectionStrings>
<add name="testString" connectionString="Data Source=ServerAddresss;Initial Catalog=DatabaseName;Integrated Security=True;" />
</connectionStrings>

C# code,

ConfigurationManager.ConnectionStrings["ProjectName.Properties.Settings.testString"].ConnectionString);

This returns a server connection string from AppName.exe.config file but I want to access it from App.config file.

can someone help me out in this?

Ravi Kumar G N
  • 396
  • 1
  • 3
  • 11
  • I'm going to go a little bit sideways with your question. I don't recommend finding a way to get your service to read from a different config file. Instead, use a config transformation so that the connection string you want is already in the one config file that's already deployed. – Scott Hannen Oct 24 '17 at 14:11
  • 1
    Hard to make sense of this, app.config only exists as a project item. Just use XmlDocument to read an xml file. – Hans Passant Oct 24 '17 at 14:46
  • @HansPassant . Yeah, that is true, just now came to know about this. – Ravi Kumar G N Oct 24 '17 at 14:50

2 Answers2

1

App.config and AppName.exe.config aren't exactly separate - AppName.exe.config is the build output of app.config.

In other words, once the service is deployed, there shouldn't even be an app.config to change, and if there is, changing it won't do anything. AppName.exe.config is where your application gets "app.config" values.

If you need different configuration values for different environments, take a look at config transformations. They allow you to change or replace sections or individual values for different configurations such as debug, release, or other custom configurations.

This is useful because it means that all of the connection strings are part of the project and are in source control. You can do without this and just edit the config file in place on the server, but then there will be nothing in source control indicating where the connection string came from. And then if you redeploy the service the change will be overwritten unless someone remembers to make the same change every time. Having it in source control is much better.

For some reason that I do not understand, you can right-click a web.config and select "Add Config Transforms", but you can't do that with an app.config. Maybe there's a good reason.

You can install this extension which enables the same behavior for app.config. Then you can right-click on app.config and add a transformation for another configuration, like Release.

In that file (app.Release.config) add this:

<connectionStrings xdt:Transform="Replace">
    <add name="testString" connectionString="...your Release connection string..." />
</connectionStrings>

When you build and deploy using the Release configuration it will replace the connectionStrings section with this one, leaving everything else just as it is. You can also right-click app.Release.config and select "Preview Config Transforms" to see the transformed file side-by-side with the original.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62
0

You should be able to just pull in an arbitrary file with a ConfigurationFileMap

System.Configuration.ConfigurationFileMap fileMap = new ConfigurationFileMap(strConfigPath); //Path to your config file
System.Configuration.Configuration configuration = System.Configuration.ConfigurationManager.OpenMappedMachineConfiguration(fileMap);

This question is a possible duplicate of: Using ConfigurationManager to load config from an arbitrary location

Also, you'll have to be sure that the service is restarted after updating the config file (either config file).

JESteph
  • 101
  • 4
  • While this works, it really just moves the problem. Now the service has to "know" that it's in a dev, QA, or production environment so that it knows which configuration file to open. How does it know that? Probably with yet another value in app.config like ``. And now instead of making sure that the connection string gets changed, you have to make sure *that* value gets changed. So in a sense you end up with a different version of the same problem you started with. – Scott Hannen Oct 24 '17 at 14:16
  • I agree with you, in general. But there could be circumstances particular to the deployment process for the OP that might make this solution for desirable. For example: instead of using a "publish" scheme, the files are manually copied into the deploy location. In which case, it might be more convenient to have a static, environmentally specific config file already deployed to the server. – JESteph Oct 24 '17 at 14:23