Make Kestrel work automatically when installed into a .csproj project

[halter73]

Right now Kestrel breaks when used from a classic .NET project using MSBuild, because libuv.dll is not automatically copied to the build's output directory. This can be worked around by manually adding libuv to the referencing project and configuring it to be copied. NuGet can do this for us though.

@natemcmaster pointed out that Microsoft.Data.Sqlite already does this.

[halter73]

@bricelam Does .NET automatically load DLLs from ./x86/ or ./x64/ based on the bitness of the loading process?

[natemcmaster]

NB you'll need to manually find libuv.dll as we do in SQLite. https://github.com/aspnet/Microsoft.Data.Sqlite/blob/6a3d31d68f2da69b2561643bfec978847a4d5a5e/src/Microsoft.Data.Sqlite/Utilities/NativeLibraryLoader.cs#L52

[halter73]

Oh... That explains why the subfolder thing works. Kestrel used to manually load libuv.dll/so/dylib, but we really want to avoid that.

#if NET451 doesn't seem to be the perfect condition for calling NativeLibraryLoader.TryLoad since it can still be true for non-msbuild projects. I guess that's why there's the IsLoaded() check. This definitely seems like a hack.

Do you know of any NuGet issues to better support this scenario?

[natemcmaster]

#if NET451 doesn't seem to be the perfect condition for calling NativeLibraryLoader.TryLoad since it can still be true for non-msbuild projects.

I believe this is why the include is conditional on "project.json".

 <ItemGroup Condition="!Exists('$(MSBuildProjectName).project.json') And !Exists('project.json')">

Do you know of any NuGet issues to better support this scenario?

Not AFAIK

[moozzyk]

I guess this is similar to what SignalR-Client-Cpp does: https://github.com/aspnet/SignalR-Client-Cpp/blob/dev/NuGet/Microsoft.AspNet.SignalR.Client.Cpp.WinDesktop.targets.template#L45-L46

[natemcmaster]

In the meantime, users can workaround this manually using MSBuild. Here is the snippet in my csproj:

    <Reference Include="Microsoft.AspNetCore.Server.Kestrel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=MSIL">
      <HintPath>..\..\packages\Microsoft.AspNetCore.Server.Kestrel.1.0.0-rc2-20202\lib\net451\Microsoft.AspNetCore.Server.Kestrel.dll</HintPath>
      <Private>True</Private>
    </Reference>
    <Content Include="..\..\packages\Microsoft.AspNetCore.Server.Kestrel.1.0.0-rc2-20202\runtimes\win7-x86\native\*" Condition="'$(Platform)' == 'x86'">
      <Link>%(Filename)%(Extension)</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      <Visible>False</Visible>
    </Content>
    <Content Include="..\..\packages\Microsoft.AspNetCore.Server.Kestrel.1.0.0-rc2-20202\runtimes\win7-x64\native\*" Condition="'$(Platform)' == 'x64'">
      <Link>%(Filename)%(Extension)</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      <Visible>False</Visible>
    </Content>

[mburumaxwell]

@natemcmaster Is there a similar workaround for a situation where a csproj uses project.json for nuget references?

[halter73]

I imagine you could still add <Content Include=. The issue is you have to find a way to reliably reference the nuget packages folder. With project.json that's usually ~/.nuget/packages.

[muratg]

MSBuild migration in the overall ecosystem will fix this

[springy76]

When? In the year 2099? 1.1 was announced weeks ago and the tooling (=SDK) still does not do what is announced in the blog posts (get rid of project.json etc.).

[bricelam]

SDK	Runtime	project.json	MSBuild
preview2	1.0 (LTS)	✔️	❌
preview2	1.1 (Current)	✔️	❌
preview3	1.0 (LTS)	❌	✔️

Look here for downloads.