TypeProviders: How to pick the correct "runtime" dll on compile-time?

[Thorium]

This is a question after debugging dll selections, and I don't know if this should go to dotnet/fsharp or here.

TypeProviders sometimes need to use external dll files, because sometimes people don't want to rewrite everything themselves.

After .NET Standard, there has been a convention that Microsoft has followed:
A nuget package contains multiple versions of dlls, for example:

• \libs\netstandard2.0\*.dll and \libs\net8.0\*.dll and so on, a file that is small in size and contains common APIs for all the calls
• \runtimes\unix\net8.0\**\*.dll and \runtimes\win\net8.0\**\*.dll that are big in size and work only on specific machine architecture.

This works well on TypeProviders on runtime assembly.

But I constantly struggle with the issue that the TypeProvider design-time / compile-time should be executable code, but it tends to pick the libs-assembly and not the runtimes assembly. Then it fails to execute the runtime code, because libs-assembly is not working as standalone. Then VS or whatever editor swallows the errors and you get a generic error.

Maybe it doesn't know compile-time is the platform even the same that it would be on user runtime.

What is the best practice here?

[Thorium]

Here is one example, but you can find similar solutions e.g. System.Threading or System.Windows.Extensions packages.

[Thorium]

By adding design-time fsproj a PackageReference with <IncludeAssets>all</IncludeAssets> you do get the runtimes to the package (under typeproviders\fsharp41), but I still don't know how to tricker loading them instead of the libs folder "common interface".

[Thorium]

For Visual Studio 2022, which is running on net472, it just works (both intellisense and compile).
But for dotnet.exe and and VSCode, running on net60, it doesn't.
Maybe because VS2022 does know its runtime environment?

More details:

• The NuGet package typeproviders\fsharp41\(framework) path endsup with a genric dll
• But to operate the typeprovider (in compile/design-time), I'd need a runtime specific dll.
• I can manually copy the runtimes folder where is the correct dll, and if I take the proper dll and replace the one in NuGet typeproviders\fsharp41 basepath, it works. In my machine, but for TypeProvider, it would be nice to work with both Windows and Unix.
• It doesn't help to give the runtime to dotnet.exe with "-r win-x64" when building my project.