dotnet / dotnet/aspnetcore

Setting `GenerateAssemblyInfo` to `false` prevents using ASP.NET Core 5 user secrets

Open
#37,901 8 comments 5 reactions 0 assignees View on GitHub
affected-few area-commandlinetools Docs feature-user-secrets
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 6h
Merged PRs (30d)
290

Description

## Visual Studio Version
16.11.5
.NET Framework 5 (SDK 5.0.402)

## Summary
Setting the `GenerateAssemblyInfo` property to `false` in an ASP.NET Core .csproj file prevents [user secrets](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-5.0&tabs=windows) from being loaded. Instead of the value stored in `secrets.json` `null` is returned.

## Steps to Reproduce

1. Create a new "ASP.NET Core Web API" project.
2. In the newly created project directory execute the command `dotnet user-secrets init`.
3. Add a new user secret by executing the command `dotnet user-secrets set "Key" "12345"`.
4. In the `ConfigureServices` method of the `Startup.cs` file add `string key = Configuration["Key"];` as the first line of the method.
5. Set a break point to the second line of the above mentioned method and build and start the program with the attached debugger. The `key` variable contains the value 12345.
6. Edit the .csproj file of the project and add the MSBuild property `false` to the existing `ProjectGroup`.
7. Compile and start the program again. The `key` variable will now contain `null` instead of 12345.

## Workaround

Add an `AssemblyInfo.cs` file to the project and add `[assembly: UserSecretsId("GUID")]` where `GUID` is the same GUID that is stored in the `UserSecretsId` property of the `.csproj` file.

## Expected Behavior

The `key` variable should still contain 12345, not `null` without being forced to add the `UserSecretsId` to the `AssemblyInfo.cs` file.

## User Impact

I've wasted several hours to figure out how to make user secrets work. There is no obvious connection between setting `GenerateAssemblyInfo` to `false` and not being able to read user secrets anymore which means that users will not figure out easily what the problem is even when doing online searches.

There is little justification for being forced to add the `UserSecretsId` attribute to the `AssemblyInfo.cs` file if it is already present in the .csproj file.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.