.NET/C# Driver Strong Naming

Alessandro_Giorgetti · August 9, 2024, 2:36pm

I really cannot understand this decision because it is a major breaking change not even emphasyzed enough in the release notes.

It will cause all sort of compile time issues all around and there’s no simple workaround (none that I’m aware of) that can mitigate the problem.

About the proposed workaround:

Delay Updating: this might not be an option, especially if new versions of the drivers fix critical bugs.
Manual Update: forking libraries (how many?), updating drivers, republish to internal nuget feeds “can be ok”, but will increase the workload on teams that actually deliver products; moreover:
- How many custom-compiled versions of the same packages we’ll see being published in nuget?
- What about “closed source” code that depends on MongoDB? are we forced to pay for packages just to update to the latest version of the driver?

Microsoft itself admits Strong Naming is a thing of the past, quoting from:

github.com

dotnet/runtime/blob/main/docs/project/strong-name-signing.md

Strong Name Signing
===================

All .NET Core assemblies are [strong-named](https://learn.microsoft.com/dotnet/framework/app-domains/strong-named-assemblies). We do this for two reasons:

1. _Compatibility_. We want to maintain type identity with previous versions of our assemblies that have shipped across various versions of our platforms. Removing a strong-name from an assembly is a breaking change, and would break the ability to consume and run libraries built against the previous identities.

2. _Serviceability_. When running on .NET Framework some of .NET Core assemblies ship locally ("app-local") with the application, this is in contrast to other framework assemblies that are placed in the [GAC](https://learn.microsoft.com/dotnet/framework/app-domains/gac). To be able to service these libraries for critical security updates, we make use of the [app-local servicing](https://blogs.msdn.microsoft.com/dotnet/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries/) feature which requires that assemblies have strong-names.

##  FAQ

### 1. Microsoft strong-names their assemblies, should I?
For the most part, the majority of applications do not need strong-names. Strong-names are left over from previous eras of .NET where [sandboxing](https://en.wikipedia.org/wiki/Sandbox_(computer_security)) needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to [isolate ASP.NET web applications](https://support.microsoft.com/en-us/help/2698981/asp-net-partial-trust-does-not-guarantee-application-isolation), is no longer guaranteed and is not recommended.

However, strong-names are still required in applications in some rare situations, most of which are called out on this page: [Strong-Named Assemblies](https://learn.microsoft.com/dotnet/framework/app-domains/strong-named-assemblies).

Because of the viral nature of strong-naming, it is recommended that publicly published .NET libraries are strong-named. Not strong-naming a .NET library excludes anyone who does need to strong-name their application or library from using it. Read more about .NET libraries and strong-naming in the [.NET Library Guidance](https://learn.microsoft.com/dotnet/standard/library-guidance/strong-naming).

### 2. I really, _really_ need to strong-name, what kinds of issues will I run into?
There are three major problems that developers run into after strong naming their assemblies:

This file has been truncated. show original

Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to isolate ASP.NET web applications, is no longer guaranteed and is not recommended.

And you also recognize that it has no benefits at all for .NET Core and .Net 5+… It might have some “benefits” only for legacy code that still runs in .Net 4.x and only for very rare (and outdated imo) situations.

I’d really like to know the actual reasons that lead you guys to break the driver contract after 9 years of publishing an unsigned package.

Why signing it now that it has no actual benefit for the current and future .Net echosystem ?