Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User secrets are not loaded into IConfiguration in a worker service on .NET Core 3.1 #2743

Closed
sethjackson opened this issue Dec 4, 2019 · 8 comments

Comments

@sethjackson
Copy link

@sethjackson sethjackson commented Dec 4, 2019

Describe the bug

In a .NET Core 3.1 worker service user secrets are no longer load from IConfiguration.

Downgrading to netcoreapp3.0 and running with the .NET Core 3.0 SDK brings back the expected behavior.

The user secrets are successfully loaded on netcoreapp3.1 in an ASP.NET Core project just not in a worker service.

To Reproduce

  1. dotnet new worker
  2. dotnet user-secrets set Test:Item Example
  3. Add _logger.LogInformation("{Item}", configuration["Test:Item"]); to the Worker class as shown below
  4. dotnet run
using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

public class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;

    public Worker(ILogger<Worker> logger, IConfiguration configuration)
    {
        _logger = logger;
        _logger.LogInformation("{Item}", configuration["Test:Item"]);
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
            await Task.Delay(1000, stoppingToken);
        }
    }
}

Expected behavior

The user secrets should be available from IConfiguration.

Additional context

dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.1.100
 Commit:    cd82f021f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\<snipped>

Host (useful for support):
  Version: 3.1.0
  Commit:  65f04fb6db
@sethjackson

This comment has been minimized.

Copy link
Author

@sethjackson sethjackson commented Dec 5, 2019

I've been investigating this a bit more.

In UserSecretsConfigurationExtensions the user secrets ID gets loaded from the assembly.

I added this to ConfigureServices:

var env = hostContext.HostingEnvironment;
var assembly = Assembly.Load(new AssemblyName(env.ApplicationName));
                    
if (assembly != null)
{
    Console.WriteLine(assembly);
                        
    var attribute = assembly.GetCustomAttribute<UserSecretsIdAttribute>();
                    
    if (attribute != null)
    {
        Console.WriteLine(attribute.UserSecretsId);
    }
}

With the .NET 3.0 SDK this outputs the ID with the .NET 3.1 SDK it does not.

Digging further it turns out that the UserSecretsIdAttribute does not exist in AssemblyInfo.cs with the .NET 3.1 SDK.

With the .NET 3.0 SDK the attribute exists in AssemblyInfo.cs:

[assembly: Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute("dotnet-test-E8F6F7FB-5F63-43EB-A338-41EC275E5892")]
@Pilchie Pilchie added the area-config label Dec 5, 2019
@Tratcher

This comment has been minimized.

Copy link
Contributor

@Tratcher Tratcher commented Dec 5, 2019

@anurse was anybody working on the Worker SDK or UserSecrets in 3.1? I'm not aware of any changes here. Regardless this looks like a regression.

@anurse

This comment has been minimized.

Copy link
Contributor

@anurse anurse commented Dec 5, 2019

There was a change to user secrets in the .NET SDK: dotnet/sdk#3673

@sethjackson can you post your full csproj file?

I think this is an issue that comes up when you transitively reference Microsoft.Extensions.Configuration.UserSecrets but not via the ASP.NET Core framework. @sethjackson does it work if you directly reference this package (if you aren't already)?

@anurse

This comment has been minimized.

Copy link
Contributor

@anurse anurse commented Dec 5, 2019

cc @dsplaisted who may have context on the original change

@sethjackson

This comment has been minimized.

Copy link
Author

@sethjackson sethjackson commented Dec 5, 2019

If I add a package reference to Microsoft.Extensions.Configuration.UserSecrets then the secrets get loaded.

However out of the box the csproj generated via dotnet new worker does not include Microsoft.Extensions.Configuration.UserSecrets in 3.0 or 3.1 so this appears to be a regression to me.

Here is my csproj:

<Project Sdk="Microsoft.NET.Sdk.Worker">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UserSecretsId>dotnet-test-E8F6F7FB-5F63-43EB-A338-41EC275E5892</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="3.1.0" />
  </ItemGroup>
</Project>
@anurse

This comment has been minimized.

Copy link
Contributor

@anurse anurse commented Dec 5, 2019

Ok yeah, I think I see the problem then. Right now, the user secrets injection only appears to work when you directly reference either Microsoft.Extensions.Configuration.UserSecrets or Microsoft.AspNetCore.App (in a Web app). It doesn't seem to support transitive reference.

Today, the best workaround will be adding the direct reference. Since it already comes transitively through Microsoft.Extensions.Hosting you don't get any other code, it just fixes the incorrect detection.

I'll file an issue on dotnet/sdk to look at solving the underlying problem (which is in that logic).

@anurse anurse added the External label Dec 5, 2019
@sethjackson

This comment has been minimized.

Copy link
Author

@sethjackson sethjackson commented Dec 5, 2019

Ok thanks!

@anurse

This comment has been minimized.

Copy link
Contributor

@anurse anurse commented Dec 5, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.