Description
AddUserSecrets<T>() depends on the presence of the UserSecretsIdAttribute decorating the calling assembly. This documentation only mentions the project setting and doesn't clarify that what this does is generate an assembly attribute, and in particular, this doesn't happen if the project was migrated from a previous version of .NET using the Migration Assistant, where .NET Framework project conventions were typically to use an AssemblyInfo.cs and therefore migration adds a project setting <GenerateAssemblyInfo>false</GenerateAssemblyInfo> since generated attributes and boilerplate coded attributes conflict. This setting indirectly and silently prevents user secrets from working. It's particularly obtuse in .NET 6 and onwards because the AddUserSecrets call is implicit in the default builder and you wouldn't think look at the method signature and deduce what it's probably doing. Passing optional: false exposes the error more clearly, but again if this is implicit in the default builder, one wouldn't think to set it.
I don't think it's practical to change the API behaviour since user secrets should be an opt-in, but when one does opt-in on a migrated project, it simply doesn't work unless you know to also change something that would seem unrelated. Therefore I think this needs to be documented more clearly.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
- ID: 9c99993c-c983-6fda-6c3a-ce4ec8c1d5db
- Version Independent ID: ba688ac2-e90e-fce5-f60d-40c2553c3efd
- Content: Safe storage of app secrets in development in ASP.NET Core
- Content Source: aspnetcore/security/app-secrets.md
- Product: aspnet-core
- Technology: aspnetcore-security
- GitHub Login: @Rick-Anderson
- Microsoft Alias: riande