Using user secrets with dotnet cli requires publishing the project.json file about usersecrets

[lcalabrese]

If you are using the Development environment to test but do not need user secrets, you can use a workaround to test for project.json:

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

    if (env.IsDevelopment() && builder.GetFileProvider().GetFileInfo("project.json").Exists)
    {
        builder.AddUserSecrets();
    }
}

[Tratcher]

It worked if I added project.json to the content section of project.json so it gets published.

[muratg]

@Bartmax Yeah, that's unfortunately the case. I guess you can remove it before restore in your build script, and copy over after publish.

[asteffes]

Does this error persist if you supply the UserSecretsId as a parameter to builder.AddUserSecrets("userSecretsId") extension method?

EDIT: I was able to recreate this bug using a "dotnet publish" command without including the project.json in the outputs and running the application.

Passing the UserSecretsId as a parameter to AddUserSecrets() method gets around this exception.

This is the work around I'll be using for deployment to our dev environment.

[muratg]

Ugh, interesting. Yeah, we don't want to project.json be there just for userSecretsId...

@anurse @davidfowl any idea where we can store this for published applications?

[analogrelay]

config.json? That is going to be a tricky one...

[muratg]

Let's look into some options in the next milestone.

[Bartmax]

I'm currently hitting this bug. Is there any workaround ? this is a RC2 web app and running dotnet run. If i remove UserSecrets it works as expected.

Unhandled Exception: System.InvalidOperationException: Unable to locate a project.json at 'C:\xxx\bin\Debug\netcoreapp1.0\win10-x64\project.json'.
   at Microsoft.Extensions.Configuration.UserSecrets.PathHelper.GetSecretsPath(String projectPath)
   at Microsoft.Extensions.Configuration.ConfigurationExtensions.AddUserSecrets(IConfigurationBuilder configuration)
   at xxx.Web.Startup..ctor(IHostingEnvironment env)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Extensions.Internal.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider)
   at Microsoft.AspNetCore.Hosting.Startup.StartupLoader.LoadMethods(Type startupType, IList`1 diagnosticMessages)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureStartup()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at xxx.Web.Startup.Main(String[] args)

[muratg]

@Bartmax You can move project.json file manually to publish folder (or write a script to to this each time you build.)

[Bartmax]

one issue i find moving the file is that next restore will try to restore the bin folder.
this have the side effect of having more log/errors/warning when dotnet restore.
not sure if it breaks anything. just wanted to let you know.

first lines of dotnet restore, with and without project.json copied over.

dotnet restore -v minimal
log  : Restoring packages for C:\xxx\project.json...

dotnet restore -v minimal
log  : Restoring packages for C:\xxx\bin\Debug\netcoreapp1.0\win10-x64\project.json...
log  : Restoring packages for C:\xxx\project.json...

[glennc]

To be clear. Are people trying to use UserSecrets in production?

[muratg]

@glennc That's not supported. The scenario here is you're testing a published app on a dev box.

[Tratcher]

Or they're running in a staging environment and hit an error they want to debug. They enable Development to turn on the DeveloperExceptionPage, and also end up with UserSecrets being turned on.
https://github.com/aspnet/Templates/blob/dev/src/Rules/StarterWeb/IndividualAuth/Startup.cs#L65
https://github.com/aspnet/Templates/blob/dev/src/Rules/StarterWeb/IndividualAuth/Startup.cs#L30

[glennc]

Yeah, I understand the issue when you want to turn on debug on the server to get some errors. It makes me think this whole setup isn't quite right. IsDevelopment has too many things hanging off it.

[muratg]

@glennc I agree. Let's talk about this. Perhaps making things more granular makes sense.

[MicahZoltu]

I just spent about 4 hours troubleshooting my deploy to find out that in production (Azure App Service) I can't call .AddUserSecrets().

I believe that the AddUserSecrets() extension method should at least be made more resilient to working under adverse conditions, such as a project.json file not being available in the expected location. Not only was this a very frustrating experience (particularly on Azure where startup exceptions are surprisingly hard to find) but also it negatively impacts the startup code readability because

_configuration = new ConfigurationBuilder()
    .SetBasePath(_hostingEnvironment.ContentRootPath)
    .AddUserSecrets()
    .Build();

has to turn into this:

var configurationBuilder = new ConfigurationBuilder()
    .SetBasePath(_hostingEnvironment.ContentRootPath);
if (hostingEnvironment.IsDevelopment())
    configurationBuilder.AddUserSecrets();
_configuration = configurationBuilder.Build();

A couple related issues:
dotnet/aspnetcore#1458
dotnet/aspnetcore#1508

[MicahZoltu]

Workaround: Create the following extension method and use it instead of the built-in one:

public static IConfigurationBuilder AddUserSecrets(this IConfigurationBuilder it, IHostingEnvironment hostingEnvironment) => hostingEnvironment.IsDevelopment() ? it.AddUserSecrets() : it;

This doesn't solve the problem of running Development environment in something like staging, just allows you to have a slightly simplified configuration setup.

[natemcmaster]

Another related issue: dotnet/efcore#5726

[natemcmaster]

This issue was moved to aspnet/DotNetTools#167