Open Newrad0603 opened 1 day ago
Tagging subscribers to this area: @JulieLeeMSFT See info in area-owners.md if you want to be subscribed.
@AaronRobinsonMSFT
@amanasifkhalid, please look into this issue this quarter.
In #47448, Jan mentioned we could add a command-line switch to disable public signing if we see a need for it. @jkotas have you changed your stance on that, or should I go ahead and add one?
It depends on how much we want to encourage mixing and matching tools from .NET Framework and .NET Core. sn
tool that has problems with this is .NET Framework specific. sn
does not exist in .NET Core. .NET Core is on public signing plan only.
https://github.com/dotnet/runtime/blob/main/docs/project/public-signing.md has more information about public signing. I think FakeSign tool mentioned in this doc can be used to workaround this issue.
Description
Attempting to generate a strong named dll that works with sn test signing is impossible with the current ILAsm behavior. As soon as a pubkey is specified, ILAsm forces the StrongNameSigned flag with no option to prevent or clear it. This means when trying to test sign an ILAsm generated assembly sn returns the error:
This conflicts with the C# compiler's behavior and means ILAsm cannot generate a dll that matches a C# compiled dll.
Reproduction Steps
1) Create a C# Class Library project 2) Target it to .NET 472 (not sure if required for repro, but that's what VS builds target) 3) Add strong name signing to project 4) Build the project 5) Run ILDasm on the dll (just used /out switch)
Expected behavior
ILAsm generates a dll that has metadata with the ILOnly corflag:
Actual behavior
ILAsm generates a dll that has metadata with the StrongNameSigned corflag:
Regression?
This works with ILAsm 5.0 or lower.
This commit introduced the issue: https://github.com/dotnet/runtime/commit/0fcfa4666685621441a1951cde7407ec7346d78c
Known Workarounds
No response
Configuration
No response
Other information
No response