DapperLib
All nuget packages to consist of strong named dll
To improve the developer ecosystem all nuget packages should only consist of strong named dll's and the current strong named package should be deprecated on nuget.org.
With this change, any downstream application/library benefits.
Same comment as here: https://github.com/mgravell/fast-member/issues/108#issuecomment-2921413046
I agree that code signing has not resulted in a great experience and is a leftover from the past. With that being said this project already has all the necessary infrastructure to do code signing as currently 2 packages are being released. 1 of which is signed and 1 is not with the only difference being the signing/name. This has fractured the ecosystem hence looking to consolidate to a single package.
Strong naming and signing are completely different things. If what you're actually saying is "strong name the main package" ... sure, but that's an identity breaking change, which is a hard break.
I don't see how signing all packages or strong naming would improve the developer experience or offer any benefit. I only foresee downsides and costs for OSS maintainers. IMHO
Let me use an example from Andrew Arnott which shows the problem link:
Consider you ship package Z and Z.Signed. Along comes nuget package M which is strong named so it depends on Z.Signed. Package N is not strong named and decides to depend on Z. Now app or package A comes along and consumes M and N. Now we have a problem, because Z.dll is in the dependency graph twice — once with a strong name and once without. The compiler of A.exe or A.dll gets all the types in Z.dll twice and you get compile errors. You also have deployment issues because msbuild tries to copy Z.dll twice. And .NET won’t be able to load both anyways.
This is a real scenario for this library due to the popularity of the library.
I acknowledge this is a breaking change hence should have been done with the v2 release.
I only foresee downsides and costs for OSS maintainers.
I fail to see this especially given that a strong named version is already being maintained hence no additional costs. in fact it lessens the packages produced/published and the snk is free anyway.
My original comment was based on the usage of the work "sign"/"signed" in the title/body respectively.
Signing and strong-naming are different things. If you'd said "strong-named", we would have had a different conversation. Sorry, not being unnecessarily pedantic: this detail really, really matters.
On the topic of "should it be strong named": in principle I entirely agree. We took this bullet over in SE.Redis and the world didn't end. It causes me pain too - it means DapperAOT cannot take a direct reference since it needs to support both libs.
Hard breaks, however, need to be carefully planned. If we do this:
- It needs to be suitably triaged, communicated, etc
- We need to do the work to look at what other breaks, if any, should happen at the same time (but have been withheld) - breaking once is undesirable but sometimes necessary, but breaking multiple times in short order is just rude
Agree with you and I know that it is important to plan these things/align with other changes. As such I see it as a good thing to have placeholder issue to capture these wishes.
On the topic of "should it be strong named": in principle I entirely agree. We took this bullet over in SE.Redis and the world didn't end. It causes me pain too - it means DapperAOT cannot take a direct reference since it needs to support both libs.
Microsoft's own documentation states that there is no benefit to strong naming for .NET 5+ .
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.
And that only strong named .NET Framework assemblies would be able to use Dapper if the main Dapper package became strong named. Non strong named .NET Framework assemblies wouldn't be able to use new versions of Dapper.
One important aspect of strong naming on .NET Framework is that it's viral: a strong-named assembly can only reference other strong-named assemblies. If your library isn't strong named, then .NET Framework apps and libraries that need strong naming can't use it.
To improve the developer ecosystem all nuget packages should only consist of strong named dll's
If applied retroactively it goes against Microsoft's best practices for .NET library developers.
❌ DO NOT add, remove, or change the strong naming key.
Modifying an assembly's strong naming key changes the assembly's identity and breaks compiled code that uses it. For more information, see [binary breaking changes](https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/breaking-changes#binary-breaking-change).
B) if you migrate and change namespace to reflect the strong naming then it goes against another best practice
❌ DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api and Contoso.Api.StrongNamed.
Publishing two packages forks your developer eco-system. Also, if an application ends up depending on both packages the developer can encounter type name conflicts. As far as .NET is concerned they are different types in different assemblies.
It is also largely unnecessary unless you're working with .NET Framework projects. .NET 5+ is the future of .NET and there is no benefit to strong naming on .NET 5+.
It is, I'll admit, very tempting to continue the status quo and quietly wait out .NET Framework's EOL...