Support AnyCPU on .NET Framework applications

[natemcmaster]

Currently this package does not support AnyCPU which means .NET Framework apps must use PlatformTarget=x64 or x86.

It is fairly easy to workaround this. We did this in the Microsoft.Data.Sqlite package by (1) adding a little managed code that locates sqlite3.dll and loads it via LoadLibraryEx and (2) adding an MSBuild target in the package to copy files to the output folder when PlatformTarget=AnyCPU.

Example: https://github.com/natemcmaster/libsqlite3-package/blob/ba16e2ede7768cf80cfe7a6023109e2c5a59e30e/files/SQLite.props https://github.com/aspnet/Microsoft.Data.Sqlite/blob/rel/1.1.1/src/Microsoft.Data.Sqlite/Utilities/NativeLibraryLoader.cs

Issues https://github.com/aspnet/KestrelHttpServer/issues/1625 https://github.com/aspnet/KestrelHttpServer/issues/1652 https://github.com/aspnet/KestrelHttpServer/issues/696

cc @davidfowl @moozzyk @muratg

[muratg]

I wonder if this is the cause of the recent scaffolding issue on a 32 bit machine. cc @mlorbetske

[davidfowl]

I was hoping this would go away when we changed to sockets by default. Maybe it's fine to do this to make .NET Framework applications work better.

TL;DR I would only do this for .NET Framework running on windows. I wouldn't change the general native library loading for anything else.

@natemcmaster does that props file only apply to .NET Framework as well?

[natemcmaster]

does that props file only apply to .NET Framework as well?

Correct. The MSBuild props is only for .NET Framework. It also means a user must have a PackageReference to libuv as MSBuild assets do not flow across project-to-project references even though native assets do. But this generally hasn't been a problem for SQLite.

[moozzyk]

Does it mean that Kestrel needs to handle loading of libuv directly instead of using DllImport?

[natemcmaster]

We can still use [DllImport("libuv")]. But before we invoke any of these extern methods we would need to manually find and load libuv.dll using LoadLibraryEx. This piece of managed code could live in the Libuv package itself, or it could be in Kestrel.

Something like this:

namespace Libuv.Interop
{
    public class LibuvLoader
    {
         public static bool TryLoadNativeLibrary()
         {
            // ...
         }
    }
}

[davidfowl]

Right. Only on .net Framework on windows.id rather not have to figure out native library loading for all platforms when the CLR already does it.

[muratg]

@moozzyk Low priority for now.