Background
On Windows, I am integrating with a .NET Core global tool that in turn loads assemblies via command line parameter assembly="c:\source\bin\Debug\netstandard2.0\JohnZabroski.Database.dll"
. JohnZabroski.Database.dll
transitively references System.Data.SqlClient
.
Problem
With COREHOST_TRACE=1
, my current stderr looks like this:
!!! Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
!!! +- Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621) ---> System.IO.FileLoadException: Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at System.Reflection.Assembly.LoadFromResolveHandler(Object sender, ResolveEventArgs args)
at System.AppDomain.InvokeResolveEvent(ResolveEventHandler eventHandler, RuntimeAssembly assembly, String name)
I found the following blogpost to be rather intimidating when trying to troubleshoot WHY my assembling could not be found or located: https://mattwarren.org/2016/07/04/How-the-dotnet-CLI-tooling-runs-your-code/
I have found Assembly Fusion Log Viewer tool in .NET 4.6 to be A LOT easier user experience. See: https://github.com/dotnet/coreclr/issues/10379
Possibly related
https://github.com/dotnet/coreclr/issues/15863 - users find debugging assembly loading on Linux to be awful (fixed: https://github.com/dotnet/coreclr/pull/15831)
Starting with @jeffschwMSFT. Please fix area-
if I'm wrong.
This is absolutely needed. It is on our backlog, but it is not likely going to make .NET Core 3.0.
This is absolutely needed. It is on our backlog, but it is not likely going to make .NET Core 3.0.
If it is "absolutely needed", why won't it be in Core 3.0? Shipping new and fancy features is great, but Microsoft's strength has always been in the tools to debug those features when they don't work. Troubleshooting assembly bind failures is a critical tool that should been built into Core from day one, and the fact that it wasn't and apparently still isn't seen as a priority is both concerning and, quite frankly, embarrassing.
Most helpful comment
This is absolutely needed. It is on our backlog, but it is not likely going to make .NET Core 3.0.