Skip to content

Instantly share code, notes, and snippets.

@natemcmaster

natemcmaster/kestrel.md

Last active March 5, 2018 18:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save natemcmaster/43a3980b724fb0b167844fb574df75dc to your computer and use it in GitHub Desktop.
Save natemcmaster/43a3980b724fb0b167844fb574df75dc to your computer and use it in GitHub Desktop.
Download ZIP
Design meeting notes: 2018-03-02 - Libuv and source build
Raw
kestrel.md

Problem

In an effort to make it possible to build ASP.NET Core from source code only on a single machine without access to NuGet.org or already-built assets, we need to revisit the structuring of our package dependencies. The NuGet package that contains Libuv bundles binaries built on macOS, Windows, and Linux. This means it is not possible to build the package, Libuv.nupkg, from source code only -- you must have multiple machines. Furthermore, because Microsoft.AspNetCore.App depends on this package via transitive reference through Microsoft.AspNetCore.Server.Kestrel, a project restore against source-built only packages cannot succeed in offline mode.

Slide1

Possible solutions

We went over ways we could solve this. This includes:

Split package graph to decouple managed packages from native packages

Split Kestrel packages into two packages following the pattern set by EFCore.Sqlite.Core/EFCore.SQLite. This would decouple packages that deliver the managed assemblies from those that deliver native binaries. The managed package binaries can be built from source, the native cannot. Remove the native package from the dependency graph of Microsoft.AspNetCore.App.

Downsides: adds more packages that can make it more confusing on which package to use.

Implement NuGet features

Create NuGet features that allow us to build a more configurable package dependency graph. For example, NuGet/Home#2391.

Downsides: more NuGet complexity, lots more work, no planned NuGet features that would solve this yet.

Rid-split Libuv

Split the Libuv package into many packages, one per supported runtime identifier. Libuv remains as a metapackage.

Downsides: doesn't solve the offline restore problem

Remove Libuv from Microsoft.AspNetCore.App

For other reasons, we already had a plan to switch the default Kestrel transport from Libuv to sockets. When we do this, we could remove Libuv from Microsoft.AspNetCore.App.

Downsides: breaking change.

Accepted solution

After discussing alternatives and options, we landed on the last solution, removing Libuv from Microsoft.AspNetCore.App. Although the first option (decoupling native from managed packages) would also have worked, we felt this added more complexity that necessary since we already wanted to make sockets the default transport.

This change will have the following implications:

  1. Change the default transport to sockets.
  2. Remove the package dependency from Microsoft.AspNetCore.Server.Kestrel to Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.
  3. Remove Libuv from the Microsoft.AspNetCore.App package graph.
  4. Keep Libuv in Microsoft.AspNetCore.All
  5. Ensure we have feature parity between Libuv and Sockets. One known gap: https://github.com/aspnet/KestrelHttpServer/issues/2231

Slide 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment