Automatically download targeting or runtime packs from transitive FrameworkReferences

[dsplaisted]

Currently, the .NET SDK will download targeting and runtime packs for all shared frameworks it knows about. For example, for a self-contained console app where the targeting packs aren't installed, it will download targeting and runtime packs for Microsoft.AspNetCore.App and Microsoft.WindowsDesktop.App, even if those frameworks aren't used at all in the app. This is because when the SDK is generating the PackageDownload items for targeting and runtime packs, it does not know if those frameworks will be required via a transitive package or project dependency. So it has to download them in case they are needed.

In order to avoid these (usually unnecessary downloads), we would need additional logic in NuGet. It could work like this:

The SDK would pass additional data to NuGet restore, in the form of a map from framework reference to a list of packages to download. For example:

• Microsoft.AspNetCore.App
  • Microsoft.AspNetCore.App.Ref/5.0.0
  • Microsoft.AspNetCore.App.Runtime.win-x64/5.0.0
• Microsoft.WindowsDesktop.App
  • Microsoft.WindowsDesktop.App.Ref/5.0.0
  • Microsoft.WindowsDesktop.App.Runtime.win-x64/5.0.0

When walking the graph, if NuGet encountered a package or a project that with a framework reference dependency, then NuGet would download the packages specified in the map. Those packages would be treated essentially as additional PackageDownload items.

This would mean that instead of preemptively downloading all of the possible targeting and runtime packs, the SDK could pass the information to NuGet that would allow only those that were needed to be downloaded.

[zivkan]

What if NuGet had some kind of DownloadPackageTask that the SDK can run on publish?

One of the things that makes NuGet's package lock files so problematic is that the restore graph changes when doing things like changing the RID. I don't like the idea of even more restore-time complexity.

Although the problem with this idea is that not all package downloading happens at restore time. Some could get downloaded at other times, like publish. Or if customers discover that NuGet has this task, they might start using it in uncontrollable places in custom targets.

[zkat]

Can you please let us know the expected customer impact on this issue, so we can reassess priority? Should we discuss it in our weekly meeting?

Ref: https://github.com/dsplaisted/ReferenceAssemblyPackages
Ref: https://github.com/dotnet/designs/blob/master/accepted/2020/targeting-packs/targeting-packs.md

[dsplaisted]

Can you please let us know the expected customer impact on this issue, so we can reassess priority?

Consumers of Maui essentials packages must set UseMauiEssentials property

A project can opt in to "Maui Essentials" by setting the UseMauiEssentials property. If a NuGet package is created from this project, it will have a framework reference to Maui essentials. Currently, projects that reference the NuGet package will have to also set the UseMauiEssentials property in order for the framework reference coming from the NuGet package to work. If they don't, they will get an error that the Maui Essentials framework reference was not recognized.

With this NuGet feature, we would be able to make it so that the framework reference flows through the NuGet package without consumers having to also explicitly opt in to Maui Essentials. See this bug for more details: dotnet/sdk#24205

Projects targeting Windows cannot be built on Mac or Linux

Projects that use WPF or Windows Forms, or that use a Windows-specific TargetFramework can only build on Windows. This is because:

• We didn't want to ship the WindowsDesktop targeting packs in the Mac/Linux versions of the SDK, as most projects wouldn't need them
• We have to download all targeting packs matching the TargetFramework whether they are directly used by the project or not, as they may be transitively referenced by NuGet packages
• So to avoid either shipping the WindowsDesktop targeting packs or having them always be downloaded on Mac and Linux, we disable them entirely if not running on Windows

This NuGet feature would allow them to be downloaded only if necessary. It is not the only thing blocking Windows projects from building on non-Windows OS's, but it is the biggest blocker and the main one that we can't address ourselves on the .NET SDK team.

We regularly get customer feedback about this. This is the issue where I've been recently trying to link all of the related issues to: dotnet/sdk#3592

Also note that it's not just about building, you can't even edit a project targeting Windows with intellisense, as the restore fails: dotnet/sdk#23218

[nkolev92]

Team Triage: We need to discuss this in more detail with @dsplaisted

[maxkatz6]

Isn't it what new dotnet workloads are for? It would make sense to install new "windows workload" to be able to edit and build net6-win projects on the machine. Though I am not against of automatic downloading.