.NET/C# Driver Strong Naming

(post deleted by author)

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.

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.

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.

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…

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.

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

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)

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

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.

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:

1. assemblyIdentity: name, publicKeyToken and culture
2. bindingRedirect: oldVersion and newVersion

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

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.

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.

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.

.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.

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 :(.

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.