Open ericstj opened 5 years ago
I do not think it makes sense to build full strong name signing into .NET Core ilasm.
If we need a full-signing in .NET Core build tooling for some reason, it should be built as separate managed tool that will handle this for all compilers.
I noticed this when playing around with ILproj projects. Our default is sign new assemblies with the open key which contains a public/private pair and this failed. We can workaround it for sure, but I felt like the "right fix" was to address it in the tool.
As a proof of concept I started migrating our .net framework infrastructure to .net 5 (rc1). We post process some assemblies with ildasm and ilasm. And I ran in exactly in this problem.
Remark: All of our assemblies are signed with a strong key, which is even checked by Anti-Maleware inside the company.
Btw... Is delay-signing possible for ilasm? Too bad I found no documentation for ildasm/ilasm nuget packages. Only the documentation in ".NET Framework Tools" hosted at microsoft.
Roslyn can do full-signing on CoreCLR, ILAsm should do the same. https://github.com/dotnet/roslyn/issues/8210
/cc @jkotas