Multiple framework target and binding redirect problem

Please let me know if this is not the right place for this type of issue.

Description

• Multiple-targeted DLL for net472 and netstandard2.0
• The .NET Framework version of the dll is put in the GAC. It has to be since it is called from code that I injected into other assemblies via the .NET Profiler API.
• After building (either in VS or msbuild command line), there is a System.Interactive.Async.dll in the binaries directory (e.g., bin\debug\net471). It is the 3.0.3000.0 version.
• I then go through my automated steps to install my assemblies into a folder from which I add all of them to the GAC (this is just for the net471 , not the netcore2.1, target).
• I reset IIS, then run a .NET Framework-based web application (it was built against .NET Framework 4.6.1)
• My profiler instruments the app, and when there is a call to my assembly, an exception occurs:

Exception Could not load file or assembly 'System.Interactive.Async, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263' or one of its dependencies. The system cannot find the file specified.

• Notice that it is not the same version as the one that was in my net471 binaries folder.

• I discovered that Grpc.Core, one of my dependent assemblies, relies on version 3.0.1000.0 of System.Interactive.Async.

• I’ve tried adding a binding redirect both from 3.0.1000.0 to 3.0.3000.0 (and the other way, from 3.0.3000.0 to 3.0.1000.0) in my assembly’s app.config. But it doesn’t seem to work.

• I even tried putting the binding redirect in a file named Grpc.Core.dll.config in the same directory as the dlls (not in the GAC though), but that didn’t help.

• Finally, I have no idea why the newer version of System.Interactive.Async.dll is even being put in my net471 binaries folder. I walked through all of the assemblies I include in ILSpy and none of them pull that in.

Any help deciphering what is going on would be fantastic. Thanks in advance!

Bob

[Green7]

I have this same problem. AssemblyResolve works:

    AppDomain.CurrentDomain.AssemblyResolve += EmbeddedAssemblyResolver;

    private static Assembly EmbeddedAssemblyResolver(object sender, ResolveEventArgs args)
    {
      if (args.Name.StartsWith("System.Interactive.Async"))
      {
        return Assembly.LoadFile(AppDomain.CurrentDomain.SetupInformation.ApplicationBase + "System.Interactive.Async.dll");
      }
      return null;
    }

[bobuva]

Ok, thanks. I may look into the AssemblyResolve option you mentioned but I know that’s a bear. Well, thanks for thinking about this. If I come up with something I’ll post it.