Note: this issue has now been resolved - see my Update 3 below for the solution.
I have an ASP.NET Core 2 web app which needs to connect to a SQL Server database. As per my Update 2 below I'm debugging the app with IIS.
I'm loading the configuration in my Program
class (because I need it for setting up logging) like this:
public static IConfiguration Configuration => new ConfigurationBuilder() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true) .AddJsonFile($"appsettings.{EnvName ?? "Production"}.json", optional: true) .AddUserSecrets<Startup>(false) .Build();
My BuildWebHost
method looks like this:
public static IWebHost BuildWebHost(string[] args) { return WebHost.CreateDefaultBuilder(args) .UseStartup<Startup>() .UseConfiguration(Configuration) .UseSerilog() .Build(); }
My appSettings.json
file has this section:
{ "ConnectionStrings": { "DefaultConnection": "*****" // secret } }
I've added a user secrets file to the project using the context menu in Visual Studio, duplicating the above section but with real connection string.
With this all in place my code throws an exception about the format of the connection string. However, if I replace "*****" in my main appSettings.json
file with the real connection string the applications works fine. So I assume it is not loading my user secrets.
Now, I thought using the overload of AddUserSecrets
passing the argument false
would cause the code to break if user secrets couldn't be loaded. But it's not breaking here. I'm not sure what else I can do. What would cause ASP.NET Core to fail to load the user secrets?
Update 1
When debugging I can see inside my Configuration property that it has the 3 providers that I'd expect: appsettings.json
, appsettings.Development.json
, and secrets.json
. However, the file root of the secrets provider is my debug path, not the location of my secrets file i.e. C:\Users[username]\AppData\Roaming\Microsoft\UserSecrets...
Update 2
I've realised that the Debug settings of the web project is pointed at an IIS site which uses an application pool running under an ApplicationPoolIdentity
user. Could this mean the user secrets need to be under C:\Users[app-pool-user]\AppData\Roaming\Microsoft\UserSecrets rather than my own user account? I've tried literally copying the GUID-named secrets.json folder over to this location but that hasn't helped. I have, however, tried changing to run under IIS Express and this time the user secrets are loaded. But for various reasons I need to be able to debug this application under a specific domain name so how can I get my user secrets to load in my IIS context? I have tried changing the app pool to use my main Windows user instead of AppPoolIdentity
but this hasn't helped.
Update 3: Solved
Well, I've learned something today! Eventually it was the answer here which solved my problem, but not in a way I expected. I moved on from my original issue - the loading of user secrets - because I realised by hosting on IIS I was essentially working with a deployment rather than a temporary debug session. So I moved my user secrets to environment variables (e.g. in my connection string example, adding a system environment variable ConnectionStrings:DefaultConnection
) and adding an AddEnvironmentVariables()
to my config setup. But I was still finding that for some reason these weren't being loaded into my configuration. Finally I discovered thanks to this SO post that IIS has a place for adding local environment variables hidden deep in a thing called Configuration Editor. Adding my variables here solved the problem and means I can now host and debug locally in IIS whilst keeping my secrets safe.
I found that when running under IIS, the secrets.json is expected to be in the Physical Path of the site.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With