Package cache support in 3.0

[tmds]

I'm not sure what the state is of the package cache with 3.0?

When building .NET Core application with our source-build sdk containers images, a huge time is spent to download packages from nuget.org.

Is some improvement coming in this area for 3.0?
Maybe we can build some of these packages from source, and then include them in the image?
Or maybe this is handled in a different way (reference packs?)?

CC @dleeapho @crummel @dsplaisted @dagood @eerhardt @omajid @aslicerh

[dagood]

This is a main thrust of dotnet/designs#50, using cleaner "packs":

This is in stark, deliberate contrast to the sdk/NuGetFallbackFolder that gets content unzipped from each SDKs .lzma, and that only grows over time no matter what you uninstall. The .lzma will be eliminated entirely and replaced by these packs.

For framework-dependent deployment, the SDK contains the targeting packs (ref) to build offline. (This is done in a more straightforward way than the package cache lzma that I expect will "just work" in the source-build context.)

The global scheme above allows for offline builds in common cases. For example, by bundling .NET Core 3.0 targeting packs with .NET Core 3.0.* SDKs, you can install the 3.0.* SDK and build framework-dependent 3.0 projects without pulling anything from the network.

For self-contained deployment, the design is currently pretty specific about the runtime packs needed for that being downloaded:

the larger runtime packs will always be acquired via NuGet.

It would make sense IMO to provide an extra RPM package containing source-built runtime packs for self-contained deployment against the machine's own RID, installing them in the packs dir, but I don't know if the SDK implementation would detect and use those.

/cc @nguerrera

[tmds]

For framework-dependent deployment, the SDK contains the targeting packs (ref) to build offline. (This is done in a more straightforward way than the package cache lzma that I expect will "just work" in the source-build context.)

This is great!!! So for building FDD .NET Core and ASP.NET Core, no nuget packages will have to be downloaded.

It would make sense IMO to provide an extra RPM package containing source-built runtime packs for self-contained deployment against the machine's own RID, installing them in the packs dir, but I don't know if the SDK implementation would detect and use those.

Makes sense to me as well. From Red Hat perspective, it's less important than improving the FDD case.

@nguerrera https://github.com/dotnet/docs/blob/master/docs/core/build/distribution-packaging.md should be updated for the targeting packs. I'm interested in reviewing, or proposing an update to the document.

[tmds]

@nguerrera reminder for the docs question.

[dseefeld]

Not an issue for 3.0