I have for some days been struggling an assembly binding error. Assembly binding is something of a black-box, where so many things can go wrong. And the error message in the exception does not give details. (at least to my understanding). So what is the recommended way to open the box of assembly binding to get details on the problem?
Specifically I am struggling with the following:
1) I have wrapped IBM.Data.Db2.Core in a .net standard 2.0 library.
2) I can nicely use that library when my application is a netcoreapp2.0
3) However when I use the library from a net461 application it fails with assembly binding
The error message is:
{"Could not load file or assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"}
I don't expect you to put your finger on the problem for me, but recommendations for opening the black box of assembly binding would be nice.
I found FusLogVw. Is that best way to get details on binding errors ?
It does not help me much though. It says assembly names are different. Looks similar to me :-(
LOG: DisplayName = System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Users/E35336/Source/Repos/Library - Db2Connectivity/Db2ConnectivityStarter/bin/Debug/net461/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Db2ConnectivityStarter.exe
Calling assembly : IBM.Data.DB2.Core, Version=1.2.2.100, Culture=neutral, PublicKeyToken=7c307b91aa13d208.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\E35336\Source\Repos\Library - Db2Connectivity\Db2ConnectivityStarter\bin\Debug\net461\Db2ConnectivityStarter.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Users/E35336/Source/Repos/Library - Db2Connectivity/Db2ConnectivityStarter/bin/Debug/net461/System.Runtime.Loader.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\E35336\Source\Repos\Library - Db2Connectivity\Db2ConnectivityStarter\bin\Debug\net461\System.Runtime.Loader.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: System.Runtime.Loader, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
fuslogvw is indeed a great place to start diagnosing assembly loads into .NET Framework apps.
System.Runtime.Loader.dll is a .NET Core assembly identity. Normally to make this work, there would be a stub version of this file that forwards to whatever assemblies contain the implementations on .NET Framework. However in this case I don't believe there is such a matching type (presumably AssemblyLoadContext) so I'm not sure how you've successfully built a .NET Standard library that uses it.
@weshaggard maybe can help. Wes I do see in http://apisof.net that it shows it in the row .NET Standard + Platform Extensions | 1.6 | System.Runtime.Loader, Version=4.0.0.0, PublicKeyToken=b03f5f7f11d50a3a
I'm not sure what this means as I don't see a netstandard configuration for System.RuntimeLoader.
I'm not sure how you've successfully built a .NET Standard library that uses it.
I did not. IBM did.
IBM.Data.DB2.Core is a netstandard2.0 library which references System.Runtime.Loader
https://www.nuget.org/packages/IBM.Data.DB2.Core/
As Dan pointed out System.Runtime.Loader is not supported net461 so if your netstandard library is consuming then you will need to exclude it while running on .NET Framework. What are you using that library for?
What are you using that library for?
I am not using System.Runtime.Loader. I am using IBM.Data.DB2.Core, and I am using it for accessing DB2 database on our IBM mainframe.
But I think I can guess what IBM is using it for. Their library is not a true .net core library. It is just a thin .net Wrapper which uses native libraries. These native libraries comes in three flavours: Windows, Linux and Mac, which is why IBM has three nuget packages (the native libraries are part of the nuget-package):
https://www.nuget.org/packages/IBM.Data.DB2.Core/
https://www.nuget.org/packages/IBM.Data.DB2.Core-lnx/
https://www.nuget.org/packages/IBM.Data.DB2.Core-osx/
A good guess is that they are using System.Runtine.Loader to load the native libraries
I can understand from both your comments that System.Runtime.Loader is a Core library, which nicely explains why it fails when I try to load it in a framework application.
Anyway. I think I understand the problem now.
@danmosemsft I too am puzzled how IBM was able to write a .netstandard library which depends on System.Runtime.Loader. That was why I was so confused.
Thank you both for your input.
Closed - seems to be answered. Shout out if I missed some angle.
I have the same problem, but no solution. Is there any?
@MarcToth what about the suggestions above? Did you try them?
I think the conclusion is that IBM wrote a crappy library.
They somehow managed to build it as .net standard, even though it is dependent on .net core libraries
FYI: That's what I found on the IBM web page:
Q: Can I use this package with full.NET framework applications?
It is not available in this release.
So we have to wait (again) for IBM to fix this...maybe...
@MarcToth, we are talking to the package owners at the moment.
https://github.com/dotnet/coreclr/issues/12707 may be related.
As I understand it, this problem is specific to 4.6.1 and earlier: on 4.6.2 and .NET Core, it works. Someone please correct me if I misunderstand.
@danmosemsft, no, 4.6.2 is not working, only .NET Core.
I just tested it with .NET 4.7.2, but it's not working either
Same problem here. Any suggestion?
Most helpful comment
Same problem here. Any suggestion?