SDK: Allow limiting runtimes folder output to a list of runtime identifiers

[NickCraver]

Is your feature request related to a problem? Please describe.

We have a space issue where a lot of space is wasted repeatedly on runtime we do not need. An example case is having developers on Windows, testing on Windows, and deploying to Linux. In total, we need to build and test on linux-64;win-x64, and only deploy to linux-x64. But as far as we can tell, nothing exists between handling a single RuntimeIdentifier (e.g. publishing) and all platforms (e.g. any normal build).

For example, let's take Mono.Posix which relies on Mono.Unix. The runtimes folder looks like this:

We need only linux-x64 (~117KB), not all 18 runtimes (6,503 KB).

This is one example, but the problem repeats for many packages. In many of our Windows/Linux scenarios roughly half the output is the runtimes folder of which we need ~30% of it. With many of these projects it adds up to about 200MB of our total 12.7GB output (which includes a lot of payloads outside .NET).

Describe the solution you'd like

I'd like to be able to filter this to the platforms we support, Windows and Linux (usually x64 but very rarely x86). For example:

  <PropertyGroup>
    <OutputRuntimeIdentifiers>liunux-x64;win-x64</OutputRuntimeIdentifiers>
  </PropertyGroup>

Additional context

I included the screenshot above to illustrate the drastic difference in current vs. output that'll ever be used. Many teams are only running on x64 these days. I'd wager most teams are not outputting for ios, androis, tvos, etc. For so many services these extra outputs add up quite a bit when we know they'll never be used. The ability to filter these out at build time (rather than some post-build cleanup step) would be a nice addition and save resources.

Note: we can't only include the filters directly since RIDs have derivatives. For example, win-x64 would need to include win and any, similarly for linux-x64 -> linux -> unix -> any. This logic for RIDs makes cleanup itself more complicated than users first expect when trying to do some post-build cleanup workaround. It'd be better/safer if this was part of the build which is aware of the RID graph.

[marcpopMSFT]

I'm wondering if we could just use RuntimeIdentifiers directly and base it off of a property that said to only PublishListedRIDs or something like that. I'm not sure we have capacity in 9 though we should look early in 10.

CC @dsplaisted for his thoughts.

[dsplaisted]

I probably wouldn't want to add more behavior to the RuntimeIdentifiers property, which currently does some things but often not what you want or expect. I think a new property that is conceptually similar to SatelliteResourceLanguages would make sense, and then you wouldn't have to enable the behavior with a separate property.

As Nick mentions, this would be a bit more complicated than simple string matching because we would need to walk the RID graph.

[emlautarom1]

We're currently facing pretty much the same issue: if we use <RuntimeIdentifier>linux-x64</RuntimeIdentifier> we avoid generating files for platforms that our product does not support, but if we want to provide a set of runtimes like <RuntimeIdentifiers>linux-arm64;linux-x64;osx-arm64;osx-x64;win-x64</RuntimeIdentifiers> then it does not work, that is, we end up with generated files for platforms that we don't care about like tvos-arm64.

Where you able to find some workaround?

[NickCraver]

Unfortunately I haven't found a clean way to do this yet either - @rainersigwald is this something the team has talked about that you're aware of?

[rainersigwald]

Not that I know of. @baronfel?