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

[ackh]

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 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 <GenerateAssemblyInfo>false</GenerateAssemblyInfo> 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.

[drewnoakes]

Thanks for the detailed issue report!

Moving to ASP.NET Core as it either belongs there or perhaps in the .NET SDK.

[javiercn]

/cc @mkArtakMSFT @adityamandaleeka @rafikiassumani-msft as I'm not sure who owns this area.

[adityamandaleeka]

Triage: the user secrets implementation depends on being able to add the assembly info, so this is expected behavior when GenerateAssemblyInfo is disabled.

We should add a note in the docs to mention this, and possibly a log message.

[ackh]

I think a better approach would be to have the build process generate the necessary code automatically. All required information to do so is available in the .csproj file. If the MSBuild property UserSecretsId is set and and the property GenerateAssemblyInfo is set to false the necessary attribute could be generated by the compiler itself. That would eliminate the redundant GUID.

[egbertn]

This is a very tricky bug, costed me time to find out what was going on. I have the same problem.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.