Rid-split the package

[natemcmaster]

Libuv.nupkg bundles Windows, macOS, and linux binaries in one file. We should rid-split this package by putting those native assets into separate packages. Then, Libuv can use runtimes.json to pull in the appropriate nupkgs for different platforms.

• Libuv
• runtime.osx.Libuv
• runtime.linux-arm64.Libuv
• runtime.win-x64.Libuv
• (etc)

[muratg]

Is this a requirement for ProdCon? I don't have a big push-back, but I want to understand the implications. (Like would publish with a rid, etc... impacted? What was the reason for making the current package "fat"?)

[muratg]

cc @shirhatti @DamianEdwards

[natemcmaster]

This is for source-build, not ProdCon. We can't build macOS and Windows binaries on a RedHat machine.

This is the same pattern used by Microsoft.NETCore.App, System.IO.FileSystem, and others to support cross-platform, standalone publishing.

[natemcmaster]

cc @jkotalik - you may be interested as the same principles will apply to ANCM

[jkotalik]

So instead of differentiating the dlls based on path, we will do it based on the nuget package name? I'm fine with that as long as the name of the dll itself remains the same across rids.

[natemcmaster]

The path inside the package is different. The goal here is that everything in a single *.nupkg file should be buildable on one machine. Today, libuv.nupkg bundles all runtimes in one, which means you cannot build the nupkg file without fanning out to multiple operating systems.

With this change libuv, it would look like this:

- Libuv.nupkg/
  + runtime.json

- runtime.linux-x64.Libuv.nupkg/
  - runtime/
    - linux-x64/
       - native/
          + libuv.so

- runtime.linux-x64.Libuv.nupkg/
  - runtime/
    - win-x64/
       - native/
          + libuv.dll

// runtime.json
{
  "runtimes": {
    "linux-x64": {
      "Libuv": {
        "runtime.linux-x64.Libuv": "1.10.1"
      }
    },
    "win-x64": {
      "Libuv": {
        "runtime.win-x64.Libuv": "1.10.1"
      }
    }
  }
}

[jkotalik]

LGTM. I can test this pattern out for in-proc and then we can port it for libuv. In-proc will only have windows RIDs but it should be the same.

[muratg]

Tentatively utting this in preview2 -- we'll be discussing this (and a couple related topics) this afternoon.

[natemcmaster]

Backlogging. We want to invest in making sockets the default transport in kestrel, so the priority of this is low. May not need to do it at all.

[natemcmaster]

At this point in our plans for the 2.2 and 3.0, I don't think this is necessary.