Ensure UserSecretsIdAttribute is added to assembly #63415
Conversation
When Microsoft.Extensions.Configuration.UserSecrets is referenced transitively, for example through Extensions.Hosting, the UserSecretsIdAttribute isn't getting added to the built assembly. This is because the logic is contained in a `build` folder which is excluded by the dependency from Extensions.Hosting. The fix is to move the logic to `buildTransitive`, so it gets picked up by NuGet. One wrinkle is that the logic now conflicts with the netstandard compatibility logic added by the library infrastructure. In order to make progress, disable that logic for this package and rely on its dependencies to raise the compat error. Contributes to dotnet#63246
|
Tagging subscribers to this area: @dotnet/area-extensions-configuration Issue DetailsWhen Microsoft.Extensions.Configuration.UserSecrets is referenced transitively, for example through Extensions.Hosting, the UserSecretsIdAttribute isn't getting added to the built assembly. This is because the logic is contained in a The fix is to move the logic to Contributes to #63246
|
|
Is it feasible to have a test? (given this was significant enough to service for) But perhaps that would have to be in the SDK repo since it involves restoring packages? |
I can add a test, but as you said, it will have to be in a different repo since this is a packaging issue. We don't currently have packaging tests in this repo. |
|
Your call, just curious. LMK if you would like me to merge. |
This one is |
I talked with @eerhardt and am OK with this. |
ghost
locked as resolved and limited conversation to collaborators
5 participants
When Microsoft.Extensions.Configuration.UserSecrets is referenced transitively, for example through Extensions.Hosting, the UserSecretsIdAttribute isn't getting added to the built assembly. This is because the logic is contained in a
buildfolder which is excluded by the dependency from Extensions.Hosting.The fix is to move the logic to
buildTransitive, so it gets picked up by NuGet. One wrinkle is that the logic now conflicts with the netstandard compatibility logic added by the library infrastructure. In order to make progress, disable that logic for this package and rely on its dependencies to raise the compat error.Contributes to #63246