add strong naming support for netstandard #803
Conversation
|
@jbevain can this get some love. happy to pay you to look into it |
|
@SimonCropp thank you as always for the PR. I'm in a bit of an intense period at work and have been lagging behind a bit on the last few new Issues and PRs. I'll get to them asap. |
|
It would be awesome if this got fixed/merged. We've just got blocked by this as well when we removed net472 targets from our assemblies and only target netstandard2.0. |
|
Hi folks, sorry it took a while to get to, thankfully I should have more time in the new year :) @SimonCropp somehow I'm not super excited at the idea of providing an API with a similar name as in the .NET Framework, even if it's only included on net standard builds. For instance, if you're referencing a Cecil built for netstandard in a .NET 4.x application you'll need to fully qualify StrongNameKeyPair because you'll see both, no? We've added I understand that pushes the responsibility of using one or the other to the user instead of having this Cecil directly which is not great. Maybe we could take this and move StrongNameKeyPair to a namespace like |
|
Could it use only the internal StrongNameKeyPair for both .NET 4.x and netstandard? |
|
@jbevain done |
| #if (NETSTANDARD) | ||
| using StrongNameKeyPair=Mono.Security.Cryptography.StrongNameKeyPair; | ||
| #else | ||
| using StrongNameKeyPair=System.Reflection.StrongNameKeyPair; | ||
| #endif |
There was a problem hiding this comment.
This creates a different and incompatible API shape between the .NET Framework and .NET Standard editions of Cecil and will break if an assembly compiled with the former uses the latter at runtime (a totally possible and supported scenario).
I had started and abandoned work on a compatible design that would solve this problem. It can be found in https://github.com/teo-tsirpanis/cecil/tree/strong-name-key-pair.
No description provided.