UserSecretsId attribute not generated when M.E.C.UserSecrets reference transitively

Overview

The logic that injects the UserSecretsIdAttribute appears to only work if the Microsoft.Extensions.Configuration.UserSecrets package is reference directly (or through the ASP.NET Core runtime). The worker template references it transitively through Microsoft.Extensions.Hosting and the attribute is never generated and user secrets are not loaded.

This was originally reported by customers: https://github.com/aspnet/Extensions/issues/2743 https://github.com/aspnet/AspNetCore.Docs/issues/14315

Repro Steps

Repro repo (just clone and skip to step 3): https://github.com/anurse/UserSecretsInWorkerRepro

1. dotnet new worker
2. Edit ExecuteAsync in Worker.cs to the following

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
        _logger.LogInformation("The secret is: {Secret}", _config["SecretName"]);
        await Task.Delay(1000, stoppingToken);
    }
}

1. Set a user secret value: dotnet user-secrets set "SecretName" "SecretValue"
2. Run with dotnet run

Expected Results

The secret value is written in a log message like:

info: UserSecretsInWorkerRepro.Worker[0]
      Worker running at: 12/05/2019 11:51:07 -08:00
info: UserSecretsInWorkerRepro.Worker[0]
      The secret is: SecretValue

Actual Results

The secret value is not present

info: UserSecretsInWorkerRepro.Worker[0]
      Worker running at: 12/05/2019 11:51:07 -08:00
info: UserSecretsInWorkerRepro.Worker[0]
      The secret is: (null)

[baltie]

Still an issue in .NET 6 RC2 with worker services. Adding a reference to M.E.Configuration.UserSecrets still works as a workaround.

[explorer14]

Sorry, but this is not really a “fix”, having a transitive and a direct dependency on the same package makes it confusing to look at for developers who might look at the two and go, “hmm…I guess it was an oversight, I will get rid of the direct ref and remove the ‘duplication’”, and that will break local development/debugging for other developers on the team. I am a bit shocked that for around a year, this has been peddled as a “fix”!

In the absence of a real fix, the next best thing would be to either:

• Manually add an AssemblyInfo.cs into the executable project and add the UserSecretsId attribute (basically what should happen out of the box), or,

• Do what @hbermani did, that also works i.e. config.AddUserSecrets(<UserSecretIdFromTheProject.csproj>)

If its in code then at least it wouldn’t be removed without somebody noticing it, redundant packages can easily be removed during refactors and they can easily sneak past PR reviews without raising suspicion.