UserSecrets: removing the dependency on project.json

[natemcmaster]

Discussion item for aspnet/Announcements#209

[KevinOrtman]

Will support be baked into Microsoft.Extensions.SecretManager.Tools to recognize this attribute?
Seems like 1.1.0-preview4-final only recognizes id's specified in project.json or on the command line.

[natemcmaster]

1.1.0-preview4-final is the last version that will support project.json. MSBuild support is already available in the 1.0.0-msbuild1-final version.

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="1.0.0-msbuild1-final" />
  </ItemGroup>

[smitpatel]

How to upgrade (project.json)
No action is required. The default configure method, .AddUserSecrets(), will fallback to read project.json for the user secrets ID.

Actually I did not get any luck at the fallback logic. I had to add the attribute to my startup assembly and I have seen multiple users hitting the same issue. Can we at least post necessary changes for upgrade scenario somewhere where we can guide users?

Error message it generates for web project with identity is like this (see aspnet/Identity#940)

No parameterless constructor was found on 'ApplicationDbContext'. Either add a parameterless constructor to 'ApplicationDbContext' or add an implementation of 'IDbContextFactory' in the same assembly as 'ApplicationDbContext'.

Which is confusing.

[natemcmaster]

cc @rowanmiller ^

Before you post guidance such as this, weigh that with its implications. The value in the assembly attribute manually is not recognized by dotnet-user-secrets and Visual Studio. Also, it will cause build failures when users upgrade to MSBuild.

[smitpatel]

cc: @divega since @rowanmiller is away.

[sschleicher208]

I have UserSecrets working correctly on my .NET 2.0 Core Web API. I also have it working correctly for my integration test suite against this same web API using the test server based on the function below (all tests pass). The problem occurs when I use the live testing. I am already using the new extension method that was previously documented to handle this bug AddUserSecrets, so I'm not sure what else to change. If I move the settings back to the regular appsetting.json and remove the AddUserSecrets call, live testing works as expected (but obviously I don't want to do that).

        public static TestServer CreateServer()
        {
            var server = new TestServer(new WebHostBuilder()
                .ConfigureAppConfiguration(config => config.AddUserSecrets<Startup>())
                .ConfigureServices((context, services) => services.AddOptions()
                .Configure<AppSettings>(context.Configuration.GetSection("AppSettings")))
                .UseStartup<Startup>());
            return server;
        }

Message: System.InvalidOperationException : Could not find 'UserSecretsIdAttribute' on assembly 'RouteManager.Core.Server'.
Check that the project for 'RouteManager.Core.Server' has set the 'UserSecretsId' build property.
If the 'UserSecretsId' property is already set then add a reference to the Microsoft.Extensions.Configuration.UserSecrets package.

[natemcmaster]

@sschleicher208 can you open a new issue? This one is closed.

[sschleicher208]

Sure thing...sorry about that.