Home > Net >  In ASP.Net MVC with .Net Framework 4.X, how do you add keys to web.config during the deployment pipe
In ASP.Net MVC with .Net Framework 4.X, how do you add keys to web.config during the deployment pipe

Time:12-28

With .NET 6 or .NET Core I can easily plug settings, connection strings, etc with environment variables, AWS Key Vault and so on.

How do I do that in .Net Framework 4.X? I want to add settings in my web.config file that cannot go to the source code repository. Transformation kinda doesn't work because the web.Release.config would also go in the repository.

A few ideas I found:

  • I could add configuration in the machine level configuration level. For my case specifically that cannot be done easily. That's why I'm looking for other ways.

  • I could create a tool that receives keys and values and then manipulate the web.config during deployment. Having to create a tool of some sort doesn't seem like the "official way of doing it".

  • I could encrypt the configuration file but then I would still have it in my repository. Even if it's encrypted it doesn't seem right. Also, there's the case I need to specify, say, the machinekey at the application level. I assume all those settings are in fact encrypted with this key, right? Then having this key open isn't secure.

I am avoiding having to change the machine level config file at all costs because that won't be easy for me to do. But maybe that is the intended way for this to be done?

How do you guys achieve production configuration in web.config files during deployment?

Ps.: I understand that I can have my code to be setup using variables, AWS Key Vault just like in .NET Core. However in this case it's a huge codebase already being fully configured through appsettings, connectionstrings, etc.

CodePudding user response:

The <appSettings> element can specify a file parameter that points to an external file (see the second example here). That file itself can be added to a .gitignore, so you effectively end up with settings that are never committed to your repo. The downside is that you have to share the contents of that secret file with any new developers.

Your P.S. makes it sound like you're already aware of the Key Vault configuration, but just in case, the other option is to directly link to an Azure Key Vault in your web.config (link). That avoids the file sharing requirement, since all of the secrets are in Azure. It's specific to Azure, though, and since you mentioned Amazon Web Services (AWS), may not quite solve your problem.

  • Related