search

brutaldev / StrongNameSigner

Strong-name sign third party .NET assemblies without the source code.
https://brutaldev.com/post/net-assembly-strong-name-signer
Other
327 stars 68 forks source link

PCL libraries that also target Silverlight get their mscorlib reference updated. #38

Closed lpperras closed 3 years ago

lpperras commented 7 years ago

We are using this NuGet package: Nito.AsyncEx.Tasks This package references this Nuget package: Microsoft.Bcl.Async

The .NET 4.0 library is a PCL library that has its Retargetable=Yes attribute in the assembly. StrongNameSigner doesn't look at retargetable assemblies and will "Fix" the reference and sign the assembly back with its own strongname.

brutaldev commented 7 years ago

I'm not sure I understand what the problem is here? What do you want/need SNS to do/not to do when an assembly has the Retargetable flag set?

lpperras commented 7 years ago

See the attached project as a sample. When I rebuild it, it'll sign assemblies in folder "packages\Microsoft.Bcl.Async.1.0.168\lib\net40" even if they already have a strong name. The reaon is that those libraries are PCL libraries that target .NET + SL, so it refers to mscorlib 2.0.5 with another public key. The asembly is also marked as retargetable, which means that even if it targets this version of the framework, it'll find the correct version of mscorlib at runtime.

The problem is that I don't think StrongNameSigner should touch assemblies that target different versions of the framework if they are already signed with another public key as they will work without touching them. POC_StrongNameSigner_Issue38.zip

brutaldev commented 7 years ago

OK cool, thanks for the explanation. Can change it to ignore assemblies that have the flag set.

The reason assemblies are re-signed even if they already have a strong-name is because of friend assembly and reference fixing. It will figure out that something in the assembly needs to change or a dependent assembly got changed so it will re-apply public keys and re-sign. I'll check out what is going on with your combination of assemblies and see if ignoring retargetable assemblies works.

Finding it difficult to make time for SNS at the moment, not sure when I'll get around to this.

lpperras commented 7 years ago

If you are okay with simply checking that flag and if that flag is set on the assembly to skip it then I might have some time to do it and I'll do a pull request.

brutaldev commented 7 years ago

Yeah, that's a reasonable solution in my mind. I'd like to do some manual testing and create a new project that compiles the flag into the assembly for unit tests and verify that it is correctly skipped and can still be loaded afterward.

jmaxxz commented 6 years ago

Having the same issue, but with the cormmon.logging package.

brutaldev commented 3 years ago

Fixed to check the retargeting flag and ignore fixing those assembly's references.