Multiple framework target and binding redirect problem
See original GitHub issuePlease let me know if this is not the right place for this type of issue.
Description
- Multiple-targeted DLL for
net472
andnetstandard2.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 the3.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 thenetcore2.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 version3.0.1000.0
ofSystem.Interactive.Async
. -
I’ve tried adding a binding redirect both from
3.0.1000.0
to3.0.3000.0
(and the other way, from3.0.3000.0
to3.0.1000.0
) in my assembly’sapp.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 mynet471
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
Issue Analytics
- State:
- Created 5 years ago
- Comments:14 (5 by maintainers)
I have this same problem. AssemblyResolve works:
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.