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
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.