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

[lpperras]

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]

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]

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]

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]

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]

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]

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

[brutaldev]

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