Dynamically loading assembly referencing Google.Cloud.Spanner.Data assembly results in binding redirect errors

Environment details

• OS: Windows 8.1/10
• .NET version: 4.5.2
• Package name and version: Google.Cloud.Spanner.Data v2.0.0 (beta8)

Steps to reproduce

1. Create an assembly which references Google.Cloud.Spanner.Data v2.0.0 package from NuGet and opens a connection
2. Dynamically load this assembly from a folder. This folder contains all assemblies (indirectly) referenced by Google.Cloud.Spanner.Data. The folder is added to the probing path of the application loading the assembly. (the application is a winforms application)

When doing so, you’ll get various binding redirect errors and you have to add binding redirects to your application’s app.config file.

This is inconvenient and IMHO also unnecessary: the nuget package for Google.Cloud.Spanner.Data v2.0.0 references other nuget packages which result in having assemblies on disk with higher version numbers for some assemblies than what they directly reference. This requires binding redirects to be applied. For a project that directly references Google.Cloud.Spanner.Data, you could add a AutoGenerateBindingRedirects element to the csproj, but for a dynamically loaded assembly this isn’t going to work.

Will this be corrected in GA/RTM? If so, then ignore my report. If not, could it be made so that the assemblies on disk reference the assemblies that are also on disk so no binding redirects are required?

TIA 😃

[jskeet]

I suspect the Google.Protobuf “issue” is because we depend (indirectly) on Google.Api.CommonProtos, which depends on Google.Protobuf 3.6.1, but we also depend (indirectly) on Grpc.Gcp depends on Google.Protobuf 3.6.0.

I don’t know what depends on System.Interactive.Async 3.1.0, but I can see that Google.Api.Gax depends on 3.2.0.

I don’t get to rerelease every dependency to make sure that everything in the entire tree lines up. In this case I “control” some of the packages, but not all of them - I’m not responsible for Grpc.Gcp, for example. Yes, I could get in touch with the people who release that, but if they update to 3.6.1 then it would be causing exactly the same problem for a different library which was using 3.6.0.

Even if I could do that, it’s very unlikely that Spanner would be used entirely on its own - if it’s in an ASP.NET Core app for example, that almost guarantees that the version of Newtonsoft.Json that ends up on disk is a later one than the earliest one referenced in the tree.

Basically, this is a bigger problem than any one package can solve - it’s a platform issue. (And note that for the most part this is within a particular major version. We have a much bigger issue in terms of dependencies across major versions.)

I’m going to close this now as effectively infeasible. I’m sorry I don’t have a happier answer for you 😦

[FransBouma]

It’s ok 😃 At least assembly redirects are possible and they solve it. I understand why it’s not really solvable now and that’s enough. 😃