Native assemblies are not being referenced?

JeffMercado · May 2022

Working on a script that utilizes ClearScript.V8 which has some native references.

Nuget References:
Esprima 2.1.3
HtmlAgilityPack 1.11.42
Microsoft.ClearScript.V8 7.2.5
Microsoft.ClearScript.V8.Native.win-x64 7.2.5

Was having trouble getting the native libraries to be detected without manually copying them over. Trying to initialize the engine I get an error:

using var engine = new Microsoft.ClearScript.V8.V8ScriptEngine();
engine.Execute(script);

Cannot load ClearScript V8 library. Load failure information for ClearScriptV8.win-x64.dll:
C:\Users\Jeff\AppData\Local\Temp\LINQPad7\_qispzlud\shadow-3\runtimes\win-x64\native\ClearScriptV8.win-x64.dll: Unable to load DLL 'C:\Users\Jeff\AppData\Local\Temp\LINQPad7\_qispzlud\shadow-3\runtimes\win-x64\native\ClearScriptV8.win-x64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
C:\Users\Jeff\AppData\Local\Temp\LINQPad7\_qispzlud\shadow-3\ClearScriptV8.win-x64.dll: Unable to load DLL 'C:\Users\Jeff\AppData\Local\Temp\LINQPad7\_qispzlud\shadow-3\ClearScriptV8.win-x64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
C:\WINDOWS\system32\ClearScriptV8.win-x64.dll: Unable to load DLL 'C:\WINDOWS\system32\ClearScriptV8.win-x64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)

Tried using the "Copy all NuGet assemblies into a single local folder" setting and I can verify the assemblies are copied over, except the native dlls.

The resolution log shows it was detected

LOG:

Expanding NuGet references for Esprima, HtmlAgilityPack, Microsoft.ClearScript.V8, Microsoft.ClearScript.V8.Native.win-x64:
  Esprima 2.1.3
  HtmlAgilityPack 1.11.42
  Microsoft.ClearScript.Core 7.2.5
  Microsoft.ClearScript.V8 7.2.5
  Microsoft.ClearScript.V8.Native.win-x64 7.2.5
Main NuGet assemblies:
  C:\Users\Jeff\.nuget\packages\Esprima\2.1.3\lib\netstandard2.1\Esprima.dll 2.1.3.0, 2.1.3.0
  C:\Users\Jeff\.nuget\packages\HtmlAgilityPack\1.11.42\lib\netstandard2.0\HtmlAgilityPack.dll 1.11.42.0, 1.11.42.0
  C:\Users\Jeff\.nuget\packages\Microsoft.ClearScript.Core\7.2.5\lib\net5.0\ClearScript.Core.dll 7.2.5.0, 7.2.5
  C:\Users\Jeff\.nuget\packages\Microsoft.ClearScript.V8\7.2.5\lib\net5.0\ClearScript.V8.dll 7.2.5.0, 7.2.5
Main NuGet native files:
  C:\Users\Jeff\.nuget\packages\Microsoft.ClearScript.V8.Native.win-x64\7.2.5\runtimes\win-x64\native\ClearScriptV8.win-x64.dll 7.2.5.0, 7.2.5
LINQPad.Runtime:
  C:\Program Files\LINQPad7\LINQPad.Runtime.dll 1.0.0.0, 7.4.2
My extensions DLL:
  C:\Users\Jeff\AppData\Local\LINQPad\MyExtensions\6.0.5( 9031FB0424F6A11B)\MyExtensions.Core3.dll 1.0.0.7653
LINQPad.Runtime.UI:
  C:\Users\Jeff\AppData\Local\LINQPad\7.4.2\LINQPad.Runtime.UI.dll 1.0.0.0, 7.4.2
LINQPad.Windows.Forms.DataVisualization.dll:
  C:\Users\Jeff\AppData\Local\LINQPad\7.4.2\LINQPad.Windows.Forms.DataVisualization.dll 1.0.0.0, 1.0.0.0

How can I get this to work?

Linqpad 7.4.2 Beta (x64)
.Net 6.0.5 Runtime

JoeAlbahari · May 2022

The code inside the ClearScript.V8 library that loads the native dependency (Microsoft.ClearScript.V8.V8Proxy.LoadNativeLibrary) has been designed to work specifically with MSBuild and not LINQPad. They've actually gone out of their way to make this happen, with a .props file for MSBuild and somewhat complex (and unnecessary) logic to manually locate the native dll in accordance to where their custom MSBuild attributes place it. It's all quite bonkers - .NET Core has a simple and well-documented mechanism for automatically resolving native dependencies via the .deps.json or ALC. They could remove all the custom logic and replace it with one line of code, which would work without any need for MSBuild magic:

NativeLibrary.Load ("ClearScriptV8.win-x64.dll", typeof (Microsoft.ClearScript.V8.V8ScriptEngine).Assembly, null);

I can only guess that it might be a hangover from a .NET Framework implementation, and whoever wrote it doesn't understand how native library resolution is supposed to work in .NET Core.

In terms of a workaround, you could try copying the native library to where that method expects to find it (this could change in the future):

File.Copy (
    (string) Util.AssemblyLoadContext.Uncapsulate().FindAssemblyPath ("ClearScriptV8.win-x64", null, true),
    Path.Combine (
        Path.GetDirectoryName (typeof (Microsoft.ClearScript.V8.V8ScriptEngine).Assembly.Location),
        "ClearScriptV8.win-x64.dll"));

JeffMercado · May 2022

Thanks, I'll try that out next time. I copied the library manually for now and it's working. Once I stabilize the script or otherwise have the time to implement the workaround, I'll give it a shot.

edit:
Workaround works fine, added to my script to run at start as needed.

ClearScript · June 2022

I can only guess that it might be a hangover from a .NET Framework implementation

That's correct, and we need that code to support a number of legacy scenarios. The problem is that it's needlessly throwing an exception in this scenario. In fact, manual loading of the native assembly is completely unnecessary with newer frameworks.

We've posted ClearScript 7.3 which addresses this issue. We've tested it with LINQPad 7 and 5. Fantastic tool, BTW 😊

JeffMercado · June 2022

Thank you very much! I can verify that it's running fine without the workaround. Even works without using the "Copy all NuGet assemblies into a single local folder" setting.

JoeAlbahari · June 2022

Thank you to the guys at ClearScript - and sorry at the frustration expressed in my message

Native assemblies are not being referenced?

Comments