mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 11:26:04 +03:00
[GH-ISSUE #38] PCL libraries that also target Silverlight get their mscorlib reference updated. #31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lpperras on GitHub (May 29, 2017).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/38
Originally assigned to: @brutaldev on GitHub.
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 on GitHub (May 29, 2017):
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 on GitHub (May 29, 2017):
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 on GitHub (May 29, 2017):
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 on GitHub (May 29, 2017):
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 on GitHub (May 29, 2017):
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 on GitHub (Apr 27, 2018):
Having the same issue, but with the cormmon.logging package.
@brutaldev commented on GitHub (Nov 2, 2021):
Fixed to check the retargeting flag and ignore fixing those assembly's references.