.NET/C# Driver Strong Naming

Alessandro_Giorgetti · 2024-08-09T14:36:22.182Z

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 ?

Andrea_Balducci · 2024-08-09T14:37:37.272Z

Open source maintainer here. Strong Naming is a thing of the past. For .Net (4.x) you should release a specific build.

This driver will break all the modern .net ecosystem, mongo will be left behind.

From ms doc about SN:

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.

Strong-names are left over from previous eras of .NET

Don’t be like IE, be like MongoDB.

Gian_Maria_Ricci1 · 2024-08-09T14:38:44.603Z

(post deleted by author)

Paulo_Morgado · 2024-08-09T14:59:06.832Z

It has been a while, and I haven’t tested it now, but I recall when a dependency became strong named (Polly???) I explicitly loaded the strong named version at start up (first statements of the application) and used AppDomain.AssemblyResolve Event to resolve references to the not strong named version.

Think of it as assembly binding redirect extended.

Gian_Maria_Ricci1 · 2024-08-09T16:06:30.071Z

The problem is that the code does not even compile. Signing an assembly generated completely different name. When My code needs to pass an instance of IMongoDatabase to a third party library you got compilation error because it cannot find the definition of IMongoDatabase unsigned.

https://jira.mongodb.org/browse/CSHARP-5206 for more reference, the problem is not binding redirect, it is the inability to even compile the code.

Paulo_Morgado · 2024-08-09T16:20:29.089Z

That happens when you are trying to reference both types (the strong named and the not strong named).

My “workaround” is for “fixing” the assembly binding.

Gian_Maria_Ricci1 · 2024-08-09T16:26:20.623Z

I’m not referencing both types, I only reference the strongly typed one, but I use another nuget package that in turn reference the unsigned one. We know that we can perform assembly redirect via configuration file or other tricks, but the problem is the inability to compile, and that is the reason why it is always a bad practice to have a 10 years old library used by many and suddently add strongly typing :(.

Assembly redirect also is cited in the link above in this post, but we have a whole different problem, we needed to have a big bang update of all dependant libraries that uses old driver…

mongodb.com

Upgrade Driver Versions - C#/.NET v2.28

Paulo_Morgado · 2024-08-09T18:06:15.474Z

I’m not arguing the hassle of an assembly changing the string name (from null to something, in this case).

But you are having compile-time issues, because you are trying the use both. Otherwise, it would be a run-time issue for that library.

If you isolate the source code using one strong name from the other, you can explicitly load the assembly at startup and resolve the old assembly to the new one. You need code for that, because the assembly binding redirects configuration only redirects versions, not names and keys.

Gian_Maria_Ricci1 · 2024-08-13T07:58:59.318Z

Actually if you are in this situation I’ve a simple github repository where I show how you can call the code through reflection

GitHub

GitHub - alkampfergit/mongo-strong-name

Contribute to alkampfergit/mongo-strong-name development by creating an account on GitHub.

in .NET 6+ you can only use reflection and it will just work (Strongly Signed is not used anymore in .NET 6+)

In .NET 4.8 you still need to do some work to manually let referenced code to find the assembly since I was not able to fix this with only assembly redirect in App.Config (redirecting unsigned to signed seems not to work)

Paulo_Morgado · 2024-08-13T08:13:52.639Z

Assembly binding redirection only works on version number, not name or strong name.

Loren_Halvorson · 2024-08-13T10:48:42.695Z

With a breaking change this impactful, I’m surprised you didn’t bump the major version number (https://semver.org/). We had absolutely no warning. Updated the NuGet’s in our dotnet8 projects and boom! everything no longer compiles. This seems like very bad behavior for such a highly popular package.

Gian_Maria_Ricci1 · 2024-08-13T11:35:09.997Z

Thanks for the info. The link in the post on official documentation cites assembly redirection and I wanted to try it avoiding maybe missing something obvious.

mongodb.com

Upgrade Driver Versions - C#/.NET v2.28

Paulo_Morgado · 2024-08-13T11:52:49.866Z

If you look at the docs: Redirecting Assembly Versions - .NET Framework | Microsoft Learn, you’ll see that assembly binding redirection is composed of 2 parts:

assemblyIdentity: name, publicKeyToken and culture
bindingRedirect: oldVersion and newVersion

You cannot redirect from one assembly identity to another. Just from one version to another in the same assembly identity.

Gian_Maria_Ricci1 · 2024-08-27T09:08:29.373Z

That is the reason why related page in this original post https://www.mongodb.com/docs/drivers/csharp/current/upgrade/#version-2.28.0-potential-breaking-change is wrong because it explain how to do binding redirect, but binding redirect does not works (as you correctly pointed out) for unsigned → signed, because they are two different types.

Carretero_Ruben · 2024-08-29T07:58:59.751Z

Is this a joke? We need to move to Atlas 8.0 as soon as it’s ready for operational use. This requires updating our driver to 2.29.0 once it’s released. We can’t wait for all our dependencies to update their MongoDB driver versions first.

Some libraries, such as MassTransit, have already updated to MongoDB driver version 2.28.0, which implies that this new version cannot be installed because the rest of the dependencies have not yet done so.

It is absurd to expect that all dependencies used in a project contain the same specific reference to another library.

We are quite surprised by this decision that blocks us and its implementation without notice. Please seriously reconsider removing this problem.

Rishit_Bhatia · 2024-08-29T19:46:21.535Z

I would like to thank everyone for their input and personally apologize for the impact that adding a strong name to our assemblies has had on all of you. It was a unanimous decision from the .NET/C# Team here at MongoDB, to ship strong-named assemblies now and do so in 2.28.0 rather than 3.0.0. Mea culpa. Hopefully the explanation below provides some context.

The .NET/C# Driver 1.X releases were strong named. We removed strong naming with the release of the 2.0 Driver in 2015. We did this because of pain experienced by users with transitive dependencies and binding redirects. Soon after the release of 2.0, users started requesting strong named assemblies via CSHARP-1276. Although Microsoft no longer recommends strong names for applications, there is still a valid use case for libraries to be strong named. This is because some environments still require strong names such as SQL Server Integration Services, Microsoft Azure Data Factory, and others. Moreso, all .NET Core assemblies themselves are strong named for compatibility and serviceability.

So what have users requiring strong-named assemblies done for the past 9 years? Two community members went to the trouble of decompiling our assemblies, strong naming them, fixing up the inter-assembly references, relinking the assemblies, and building strong-named NuGet packages. They released unofficial strong-named packages such as MongoDB.Driver.signed. I would like to personally thank them for doing this for as long as they did. But for whatever reason they stopped publishing these strong-named packages with the 2.19.0 release. This left our strong-named users and partners without access to new features and bug fixes.

There are other 3rd party libraries like AspNetCore.Diagnostics.HealthChecks which have already been updated to the newer strong named version. Albeit painful, this is a one time change to be done. We understand the challenge with transitive dependencies and are open to reaching out to collaborate with other 3rd party open source developers to request them to update their MongoDB dependencies. Please let us know if we can help in doing so.

PS: MongoDB Atlas 8.0 does not necessarily need the driver version 2.29 and above, it will work with older versions of the driver as well. However, there are some capabilities that will be introduced in future versions of the driver like Range Indexes in v2.29 and Improved Bulk Write in v3.0 respectively.

Gian_Maria_Ricci1 · 2024-08-30T07:24:53.940Z

It would be beneficial to continue to produce in the nuget package a .NET 5 version that is still not strongly typed. This because in .NET 5 and above, Strongly Named is not used anymore so you do not have any advantages, only problems.

At least everyone that is on .NET 5+ will be unaffected by the change. I know that this is more work for you, but actually it should be not very complicated to have two build. So you can produce .NET 4.8 signed .netstandard 2.0 signed, but .NET 5 unsiged

This will at least lessen the impact.

Paulo_Morgado · 2024-08-30T08:18:33.117Z

.NET 5 is long out of support and I wouldn’t target that for anything. Starting next November, .NET 8.0 and 9.0 will be the only supported runtimes.

As inconvenient as this is, the problem was created when strong naming was removed, not now. After a while, this will no longer be a problem.

Nevertheless, since the issue was caused by MongoDB, MongoDB should provide proper complete and correct guidance. And that could be a repo that users can build the driver from.

Gian_Maria_Ricci1 · 2024-09-17T10:58:48.276Z

A typical example. In our project we use GitHub - elsa-workflows/elsa-core: A .NET workflows library and uses mongodb extensions. We use Elsa 2 (moving to 3 has too much breaking changes). The version 2 is still using an old version of the driver.

Since we are extending some other classes, using reflection to call those extensions is literally a nightmare. Now we should hope that Elsa maintainer wants to patch an old version to support strongly type version of the driver. Elsa is a .NET core project so it does not benefit from strongly typed naming, but it is impacted too :(.

Gian_Maria_Ricci1 · 2024-09-17T15:24:05.813Z

Trying to fork elsa mongodb support to upgrade driver does not works because it uses MongoDb.Bson.NodaTime that uses old driver. So I use a library, that uses a second library I fork that second library and I need to fork the third library, now I need to fork the fourth library … seriously … this is a nightmare.

You put us developer in an infinite hell of fork and a maintenance nightmare, even if in .NET core signed assembly is absolutely an unused feature…

I’m absolutely tired, the only solution is to stick to the older driver and probably never update because there are too many libraries that are old and not maintained and we need to fork an ecosystem.