Strong Naming

[lukebakken]

Hello!

I wanted to try out Fixie for some new RiakClient tests, but can't since Fixie is not strong named.

I tried decompiling and re-compiling Fixie.dll using our key to sign it, but then the VS test runner can't load the DLL since it is trying to bind an assembly with a null PublicKeyToken.

Please consider strong naming Fixie, and refer to octokit/octokit.net#405 for extensive discussion. We decided to strong name RiakClient based on this, and adopted the assembly versioning strategy based on the discussion as well.

[JohnStov]

Please please please please don't!

Let me point you to what Paul Betts said on the subject when it was raised on the ReactiveUI list.

reactiveui/ReactiveUI#43 (comment)

[jbogard]

@JohnStov what problems would you have if Fixie were strong named?

[lukebakken]

When done right, (i.e. checking in the key for strong naming), there is zero friction for contributors. This is what we have done for RiakClient. A potential contributor can clone the project, build it, and have it strongly named, with zero effort on their part.

The thread to which I linked explained everything better than I could, and we have decided to stick with NUnit in RiakClient due to this issue, so I don't have anything further to add here.

[JohnStov]

@jbogard - I don't know for sure, but my big worry is that it would make the ReSharper plugin harder, if not impossible to implement. (I am working on the RS9 plugin, honestly...).

For the vast majority of people it's just additional friction. I avoid newtonsoft.json because of the grief it's caused me in the past...

It's hard enough trying to persuade people to switch to Fixie, without having to tell them they're going to have to deal with strongnaming issues too.

[jbogard]

What friction? I kept bringing this up on that thread but never received any notion of what pain people were feeling, unless it was "I have a massively popular OSS project that a lot of other OSS projects depend on" like JSON.net.

This is what I hit in removing SN in AutoMapper. Had it SN'd, zero complaints in 7 years. Removed SN, complaints. Both were equal work to me, having/not having SN, so I put it back in.

[lukebakken]

This is what I hit in removing SN in AutoMapper. Had it SN'd, zero complaints in 7 years. Removed SN, complaints. Both were equal work to me, having/not having SN, so I put it back in.

This is the main reason we decided to SN RiakClient - @jbogard's experience with AutoMapper.

[jbogard]

Hey FYI you can use the StrongNamer package to strong name all packages at compile time. It's what I'm using for MediatR.

[lukebakken]

Thanks for the tip.

[plioi]

As Jimmy suggests, our recommendation for Fixie will be to use StrongNamer instead. See similar discussion here: jbogard/MediatR#86

[SimonCropp]

So have been one of the strong advocates for "dont strong name".

I was the one who pushed for "Do not rely on strong names for security. They provide a unique identity only" to be added here: https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

However the community has spoken and strong naming has won. If you want a project to get wide adoption, that adoption will be hampered by lack of strong naming.

The packages mentioned in this issue (MediatR, AutoMapper, RiakClient, and Octokit) are all now strong named

Much of the friction of strong naming can be avoided by pinning the assembly version. so you never change it from what it is currently. This will stop any binding redirect issue. This is the approach newtonsoft eventually adopted

so it is with great disappointment in our community and myself, that i suggest you reconsider strong naming your assemblies

[plioi]

From the Linked Documentation

For .NET Framework, strong-named assemblies are useful in the following scenarios:...

In contrast to that section we see:

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

And it ends with (emphasis added):

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework...

From Related Documentation

From the related page https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming we have:

.NET 5+, .NET Core, ... don't have strict assembly loading
...
The benefits of strong naming on .NET Framework are:
...

Strong naming has no benefits on .NET Core/5+. C# compiler produces CS8002 warning for strong-named assemblies referencing non-strong named assemblies. It is fine to suppress this warning for libraries that target .NET Core/5+ only.
...
You should strong name your open-source .NET libraries if their targets include .NET Framework or .NET Standard. Strong naming is not required for libraries that target .NET Core/5+ only.

That last point about .NET Standard is likely in reference to netstandard2.0 or earlier only, since that would imply .NET Framework consumers exist.

Regarding the warning, those who set all warnings as errors and then choose to create a problem by not suppressing CS8002 will be advised to uncreate that problem.

Dotnet Team Discussion

Even folks at Microsoft, understandably, were surprised by the change in the .NET Core era, but thankfully they captured this conversation for reference: dotnet/docs#22412

In that conversation we have:

1. While tempting to think the identity aspect of strong names would still offer material benefits, even if the GAC concerns were now irrelevant, such as loading two assemblies with coincidental names but different strong names, even that is simply not true for .NET Core and .NET 5+.

2. They saw strong naming creating many problems and having diminishing value, and ignoring them for assembly binding is a deliberate choice.

3. Several open source projects are shown linking to this discussion, all over approximately the last year. The consistent response from the community is that there was only utility for .NET Framework users. Even then, each team that had some dwindling fraction of .NET Framework consumers had to weigh effort and risk vs reward; there is no such thing as blanket guidance.

Strong Naming Concept May be Dropped

Related, the Program Manager on .NET had the following to say in a thread where he was debating dropping the concept from .NET 8 altogether: https://twitter.com/terrajobst/status/1575848512192847873

On .NET Core there isn't any [benefit] really as the runtime completely ignores it and never validates it.

Mentioned Packages in This Thread

1. MediatR - v12.2.0 targets netstandard2.0 and therefore likely still has many .NET Framework consumers. I worked with the maintainer and we used this on many .NET Framework projects. The API surface here is deliberately small, so it may stick with netstandard2.0 indefinitely, and so would be concerned with maintaining the strong naming indefinitely.

2. AutoMapper - v12.0.1 targets netstandard2.1 and therefore doesn't have .NET Framework consumers any longer. It could probably do with dropping strong naming, though the act itself might best coincide with their next major release and the maintainer may prefer not bothering. There may or may not be a hidden cost to dropping it even if it now has no utility. It last had a potential need for strong naming back in v10.1.1 when it targeted netstandard2.0 and net461 a few years ago.

3. RiakClient - v2.5.0 targets net40 which is only natural as that repo was last active in 2017.

4. Octokit - v9.0.0 targets netstandard2.0 and is in the same boat as MediatR.

5. Newtonsoft.Json - v13.0.3 targets all the way back to net20 and naturally has a bonkers number of .NET Framework users.

Fixie

Fixie v3.4.0 targets netcoreapp3.1, net6.0, net7.0, and net8.0. It hasn't targeted .NET Framework (nor indirectly via netstandard), for 859 days, and there have been three major versions of .NET since then, each of which ignores strong names.

We dropped .NET Framework support for a few reasons once it was clear from Microsoft messaging that it was lapsing into legacy. Some of the reasoning for the aggressive drop there was that getting the VSTest integration to work for both Framework and Core was startlingly complex, accounted for >90% of time spent in development, and blew up the end-to-end QA effort on each Fixie release. At the time, users of Fixie on .NET Framework would use v2 and also at the time the community consensus was to "punt" the workaround (StrongNamer) to the end users who were opting into the pain, rather than taking on a workaround themselves.

Strong naming now would mean opting into something viral (even if only via CS8002 and unsupported community momentum), that offers no material benefit to the project, that many members in the community are avoiding too for that reason, and that would force me to immediately and permanently take part in a workaround by materially damaging/faking assembly metadata, since even back when this did have a material effect the material effect was so immediately wrong for real users that the workaround had to be debated and crafted over years of arguments. I would sooner delete the repo, unlist the packages, and defenestrate my laptop.

[SimonCropp]

@plioi thanks for the comprehensive answer. and i full respect your decision