Add Microsoft StrongNameKey back to System.Composition* - #45756
Conversation
|
Tagging subscribers to this area: @safern, @ViktorHofer Issue DetailsRegressed with dotnet/corefx@9a4ed0d#diff-739e1ffbaee417f430131875c0471f5ab63a11561f06de857adcd32f4eddce15L5 and was reported via #45638.
|
|
/backport to release/5.0 |
|
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/408248639 |
| <Import Project="..\Directory.Build.props" /> | ||
| </Project> No newline at end of file | ||
| <PropertyGroup> | ||
| <StrongNameKeyId>Microsoft</StrongNameKeyId> |
There was a problem hiding this comment.
Is there an APICompat run that should have caught this or is APICompat ignoring PKT?
There was a problem hiding this comment.
That's my assumption as well. I believe APICompat currently doesn't validate the PKT in the assembly metadata:
.assembly extern System.Composition.AttributedModel
{
.publickeytoken = (CC 7B 13 FF CD 2D DD 51 ) // .{...-.Q
.ver 5:0:0:0
}
There was a problem hiding this comment.
I know there were some intentional differences, back in Silverlight days and the runtime supported it. Those should be paired with [assembly: AssemblyFlags(AssemblyNameFlags.Retargetable)]. I wonder if we could add this attribute to make it compatible with folks who compiled against the bad PKT 🤔
cc @safern who's looking at API compat scenarios.
|
Does this change fix the underlying reason why we broke this twice? 🙂 |
Nope, this PR doesn't switch away from MSBuild as the build engine. Jokes aside, I filed https://github.com/dotnet/runtime/issues/45899 to track validation for strong name keys. |
ghost
locked as resolved and limited conversation to collaborators
4 participants
Regressed with dotnet/corefx@9a4ed0d#diff-739e1ffbaee417f430131875c0471f5ab63a11561f06de857adcd32f4eddce15L5 and was reported via #45638.