Ignore strong names
I was using way too long hunting down the reason for a CS0012, I had the assumption that a non strong named assembly reference can bind to a strong named assembly reference just not the other way around which I thought was logical. (btw an error message with more info could have been useful)
But yeah, no some debugging and browsing of roslyn code base eventually made me notice that if either is strong named both must be.
This means nuget packages that come shipped strong named (like newtonsoft.json) will break comparability with older libraries, potentially, and including in my case, some you don't have control over.
Older versions, in most cases, works just fine in my use case.
So the question is, does MSBuild or the <PackageReference> tag it self have a way to either:
1. Ignore the strong name binding rule and don't emit it in metadata (but leaving potential build output with strong named assemblies that can be patched if nessesary) or,
2. preferably, strip the strong name binding entirely before building.
Or am I really forced to reupload a strong name stripped version my self?
I'm sure someone else has found this annoying, or am I missing something here?
I noticed some library authors have decided to offer a strong named assembly separately, so some people seems to have gotten the message.
I am not mentioning at runtime since that is disabled in the runtime by default? atleast by some configurations, regardless it can be easily hacked at runtime by resolve events.
2 Replies
assemblies that consume strong-name-signed assemblies do not also have to be strong-name-signed.
No but in my case I have a dependency that reference Newtonsoft.Json 8.0.0.0 unsigned, that I don't have control over. While my project reference Newtonsoft.Json 13.0.0.0 from nuget that is signed by newtonsoft.
As I said above if my project referneces something from the dependency that has the different newtonsoft.json in it's signature the CS0012 error happens because of the strong name of the nuget version eventhough they are compatible just fine otherwise.
This senario could have been as trivial as version 13.0.1 vs 13.0.2 and the strong name would still have broken the compatability