ILAsm versions 6.0 or higher force the strong name signed corflag which conflicts with sn test signing

[Newrad0603]

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:

A fully-signed strongly named assembly cannot be test-signed.

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)

C:.tools.nuget\packages\runtime.win-x64.microsoft.netcore.ildasm\8.0.0\runtimes\win-x64\native\ildasm.exe C:\source\repos\ClassLibrary3\ClassLibrary3\bin\Debug\net472\ClassLibrary3.dll /out=C:\source\repos\ClassLibrary3\ClassLibrary3\bin\Debug\net472\ClassLibrary3.il 6) Run ILAsm on the il generated by Step 4 (just used /out and /dll switches) C:.tools.nuget\packages\runtime.win-x64.microsoft.netcore.ilasm\8.0.0\runtimes\win-x64\native\ilasm.exe /dll C:\source\repos\ClassLibrary3\ClassLibrary3\bin\Debug\net472\ClassLibrary3.il /out=C:\source\repos\ClassLibrary3\ClassLibrary3\bin\Debug\net472\ClassLibrary3.roundtrip.dll

Expected behavior

ILAsm generates a dll that has metadata with the ILOnly corflag:

.module ClassLibrary3.dll // MVID: {7682CDED-E5A8-457D-8D04-B3DE8D9CB617} .imagebase 0x10000000 .file alignment 0x00000200 .stackreserve 0x00100000 .subsystem 0x0003 // WindowsCui .corflags 0x00000001 // ILOnly .custom instance void System.Runtime.CompilerServices.RefSafetyRulesAttribute::.ctor(int32) = ( 01 00 0b 00 00 00 00 00

Actual behavior

ILAsm generates a dll that has metadata with the StrongNameSigned corflag:

.module ClassLibrary3.dll // MVID: {56F5FA36-E443-4FD2-966F-B95698FB7403} .imagebase 0x10000000 .file alignment 0x00000200 .stackreserve 0x00100000 .subsystem 0x0003 // WindowsCui .corflags 0x00000009 // ILOnly, StrongNameSigned .custom instance void System.Runtime.CompilerServices.RefSafetyRulesAttribute::.ctor(int32) = ( 01 00 0b 00 00 00 00 00

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

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @JulieLeeMSFT See info in area-owners.md if you want to be subscribed.

[Newrad0603]

@AaronRobinsonMSFT

[JulieLeeMSFT]

@amanasifkhalid, please look into this issue this quarter.

[amanasifkhalid]

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?

[jkotas]

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.