3

Wondering if anyone has used a database as a repository of connection strings or app settings that could be use for multiple web applications across multiple different servers?

All of our web api applications have connection strings to logging database and tracing database and I know that in the next 6 months those databases will change location. With out going into each web.config setting I would like to refactor the web services other the next few months to point to a central repository for this connection string (and others).

I try very hard to avoid Machine.config which is why I have the connection string in each web.config.

We are using redis for session management and I thought about using one of the database for this since it's ultimately a key-value pair. Has anyone use it in that matter?

How have some of you gotten past this issue?

As this has been marked as too broad, let me see if I can add more details. We have close to 50 web services that ALL have the same connection string within in the web.config and are located on multiple different servers. I would like to possible edit these services to use a shared resource so that when the connection string changes we would only need to edit a single resource instead of redeploying each web service and/or editing each web.config. I am not a fan of using the machine.config.

Rodney Pannell
  • 330
  • 5
  • 16

1 Answers1

2

While you can perfectly use Redis or any database to store such global settings, maybe what you need is a build script.

If you're in the .NET world, I guess you know what's Team Foundation Server, which also provides Team Foundation Build.

Instead of hardcoding those settings like connection strings, usually you would provide them as custom build properties that can be used to replace some placeholder in your files. Your files would look as follows:

<add name="myConnectionString" connectionString="server=%host%;database=%database%;uid=%user%;password=%password%;" />

Since TFS 2015, TFS Build has a scriptable build system so you can add a Powershell step to replace placeholders with actual values from the build configuration (see this other Q&A to learn more: How to replace multiple strings in a file using powershell).

Once you've replaced the placeholders, you can add a deploy step and deploy the whole application to some machine using FTP, WebDeploy or other protocols.

In summary, maybe your best bet is avoiding hardcoded configurations even in web.config if they might be different depending on the deployment, and these variable settings can be injected using a build script. That is, when you change some configuration, you do it in the build custom properties, and then you deploy your applications again with the configuration changes.

This page should be a good start for you to investigate this approach further: https://www.visualstudio.com/en-us/docs/build/define/build

Also, check Visual Studio Team Services on Azure, a variant of TFS hosted in Azure.

Community
  • 1
  • 1
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
  • While you are very correct, I build script ofter when deploying our website, I don't want to redeploy or edit close to 50 web services when the database changes. I would rather edit a single location and after some caching clears up everything start using the new database. – Rodney Pannell Oct 17 '16 at 11:50
  • @RodneyPannell But with WebDeploy you can synchronize modified files only. Actually just the web.config. Or you can use WinSCP with synchronize command. **A single build can execute these 50 deployments**. Why not? You do it once and you just care about clicking a button to queue a build! – Matías Fidemraizer Oct 17 '16 at 14:26