LinqPad7 runtime identifier win10-x64 vs win-x64

A recent issue with LinqPad 7 running as .Net 6.0, and the SqlitePCL.Raw sqlite native libraries prepared by Eric Sink.I am not sure on which side the problem lies.

When running as a .Net 6.0 runtime, and referencing NuGet packages also compiled as .Net 6.0, and when trying to resolve a native assembly reference, LinqPad identifies its runtime as win10-x64.

When configured as 6.0, LinqPad throws Unable to load DLL '\.nuget\packages\SQLitePCLRaw.lib.e_sqlite3\2.0.7\runtimes\win10-x64\nativeassets\net6.0-windows10\e_sqlite3.dll' or one of its dependencies: The specified module could not be found. (0x8007007E). And dumping the assembly resolution log shows it is resolving to the win10-x64 subdirectory of the native runtimes.

When configured as 3.1 and referencing NuGet packages compiled with .Net 3.1, the assembly resolution log shows it is resolving to the win-x64 runtime subdirectory, and the code runs just fine.

One might think this is a problem on the SQLitePCL.raw side, and it very well may be, but I have one other observation.
If I take the exact same .Net 6.0 code and NuGet packages, and run them as a Console application with VS 2022, everything compiles and runs fine. VS2022 copies the "runtimes" folders from the NuGet package into the bin/Debug directory. However, it copies only the win-x64 subfolder and not the win10-x64 subfolder!

So my question is if there a way to configure LinqPad 'runtime identifier' as win-x64 instead of win10-x64? Seems being able to switch the runtime identifier also resolved a similar problem with e_sqlite3 and MAUI by adding <RuntimeIdentifier>win-x64</RuntimeIdentifier> to the csproj file.


Sign In or Register to comment.