Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.While working on my new side-project in ASP.NET Core, I was at the point where I needed to start storing sensitive configuration data. Things like my DocumentDB Auth Key, Google OAuth ClientId & Secret, Twilio Auth Token, etc. Depending on your context you may not want to be storing these types of application settings in configuration files that are committed to source control. As you would expect, my local environment for development and once I deploy to Azure have completely different configurations. So how do you change the configuration from local to production? If you are used to using
web.config, you may have been going down the road of transforming and replacing values with tools like SlowCheetah or through Octopus Deploy. With ASP.NET Configurations, there’s a new way to do this. If you have any questions, please follow me on Twitter.
ConfigurationASP.NET Core has a
ConfigurationBuilderthat enables you to load application settings from various places. If you’ve loaded up a brand new ASP.NET Core app, you’re Startup looks something like this. You have a new
appsettings.jsonfile you can use as well as an optional appsettings for each different environment. I could use the
appsettings.Development.jsonfor local development, however as mentioned i want to keep sensitive data out of this file. For this, I’ve now been using User Secrets.
User SecretsASP.NET Core adds a new way to store your sensitive data with User Secrets. User Secrets are simply a plain text json file that are stored in your systems user profile directory. Meaning the file is stored outside of your project directory. There are a couple ways to manage your user secrets, first you need to add
Microsoft.Extensions.SecretManager.Toolsin the tools section of your
project.json. I’m unaware of how this translates to the new .csproj format. If you are using the dotnet CLI, then you should now be able to run
dotnet user-secrets --versionNext in your project.json you want to add a “
userSecretsId” property in the root. The value can be anything you want but should probably keep it unique so it doesn’t collide with another user secrets you create for any other project. In order to load the secrets file, you need to first add
Microsoft.Extensions.Configuration.UserSecretspackage in your
project.jsonAs mentioned, since I only use user secrets for local development, we can now load the secrets using the
ConfigurationBuilderin our Startup
Visual StudioIf you are using Visual Studio, you can edit your user secrets file by accessing it in the context menu of your project in the solution explorer.
CLIIf you are using the dotnet CLI then you can call
dotnet user-secrets [options] [command]to clear, list, remove and set secrets.
ExampleSimple example would be wanting to store the connection string to a database.
dotnet user-secrets set ConnStr "User ID=Derek;Password=CodeOpinion;"Now within our code we can access the connection string after we built our configuration from the ConfigurationBuilder.