Runtime: COREHOST_TRACE sollte AssemblyLoadContext protokollieren

Erstellt am 16. Apr. 2019  ·  3Kommentare  ·  Quelle: dotnet/runtime

Hintergrund
Unter Windows integriere ich ein globales .NET Core-Tool, das wiederum Assemblys über den Befehlszeilenparameter assembly="c:\source\bin\Debug\netstandard2.0\JohnZabroski.Database.dll" lädt. JohnZabroski.Database.dll verweist transitiv auf System.Data.SqlClient .

Problem
Mit COREHOST_TRACE=1 sieht meine aktuelle Stderr so aus:

!!! 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)

Ich fand den folgenden Blogpost ziemlich einschüchternd, als ich versuchte, zu beheben, WARUM meine Assemblierung nicht gefunden oder gefunden werden konnte: https://mattwarren.org/2016/07/04/How-the-dotnet-CLI-tooling-runs-your -Code/

Ich habe festgestellt, dass das Assembly Fusion Log Viewer-Tool in .NET 4.6 eine VIEL einfachere Benutzererfahrung ist. Siehe: https://github.com/dotnet/coreclr/issues/10379

Möglicherweise verwandt
https://github.com/dotnet/coreclr/issues/15863 – Benutzer finden das Laden von Debugging-Assemblies unter Linux schrecklich (behoben: https://github.com/dotnet/coreclr/pull/15831)

area-AssemblyLoader-coreclr enhancement

Hilfreichster Kommentar

Dies ist unbedingt erforderlich. Es befindet sich in unserem Rückstand, wird aber wahrscheinlich nicht zu .NET Core 3.0 führen.

Alle 3 Kommentare

Beginnend mit @jeffschwMSFT. Bitte korrigieren Sie area- , wenn ich falsch liege.

Dies ist unbedingt erforderlich. Es befindet sich in unserem Rückstand, wird aber wahrscheinlich nicht zu .NET Core 3.0 führen.

Dies ist unbedingt erforderlich. Es befindet sich in unserem Rückstand, wird aber wahrscheinlich nicht zu .NET Core 3.0 führen.

Wenn es "absolut benötigt" wird, warum wird es dann nicht in Core 3.0 sein? Die Bereitstellung neuer und ausgefallener Funktionen ist großartig, aber die Stärke von Microsoft lag schon immer in den Tools zum Debuggen dieser Funktionen, wenn sie nicht funktionieren. Die Fehlerbehebung bei Assembly-Bind-Fehlern ist ein wichtiges Tool, das vom ersten Tag an in Core integriert sein sollte, und die Tatsache, dass dies nicht als Priorität angesehen wurde und anscheinend immer noch nicht angesehen wird, ist sowohl besorgniserregend als auch, ehrlich gesagt, peinlich.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen