[release/6.0] Ensure UserSecretsIdAttribute is added to assembly #63423
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. Note, we also need to service the Extensions.Hosting package so it references the new UserSecrets version by default. Fix dotnet#63246
|
Tagging subscribers to this area: @dotnet/area-extensions-hosting Issue DetailsBackport of #63415 to release/6.0 Customer ImpactCustomer reported break from 5.0. In 5.0, a developer could use the "User Secrets" functionality without modifying a "Worker" templated app. In 6.0.0, we made packaging changes that caused the "User Secrets" functionality no longer work out of the box. The developer would have to directly reference the RegressionYes. 5.0 worked correctly. 3.1 had this same problem, but we re-broke it in 6.0. TestingManually tested the produced packages (Hosting and UserSecrets) work correctly to add the attribute when the project only references Hosting. RiskLow risk in that this only moves the build logic to be used whenever the package is referenced, even transitively. In 6.0.0, the build logic was only used when the package was referenced directly. 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 The fix is to move the logic to Note, we also need to service the Extensions.Hosting package so it references the new UserSecrets version by default. Fix #63246
|
leecow
added
Servicing-approved
|
@eerhardt ready to merge? |
Yes. The only test failure is #62068. |
ghost
locked as resolved and limited conversation to collaborators
5 participants
Backport of #63415 to release/6.0
Customer Impact
Customer reported break from 5.0. In 5.0, a developer could use the "User Secrets" functionality without modifying a "Worker" templated app. In 6.0.0, we made packaging changes that caused the "User Secrets" functionality no longer work out of the box. The developer would have to directly reference the
Microsoft.Extensions.Configuration.UserSecretspackage in order for it to work.Regression
Yes. 5.0 worked correctly. 3.1 had this same problem, but we re-broke it in 6.0.
Testing
Manually tested the produced packages (Hosting and UserSecrets) work correctly to add the attribute when the project only references Hosting.
Risk
Low risk in that this only moves the build logic to be used whenever the package is referenced, even transitively. In 6.0.0, the build logic was only used when the package was referenced directly.
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.Note, we also need to service the Extensions.Hosting package so it references the new UserSecrets version by default.
Fix #63246