Support flowing workload dependencies through project and package dependencies

[dsplaisted]

Workload dependencies should be able to flow through project and package dependencies. IE, if a project depends on a workload, projects which reference the project may need to also depend on that workload.

For iOS and Android workloads, the TargetFramework is what lights up the workload, so in that case the dependencies automatically depend on the same workload because they need to use a compatible TargetFramework. However, projects using .NET Maui can put shared logic in a project with a TargetFramework of net6.0, and set the UseMauiEssentials property to true to opt in to the Maui workload. We currently don't have a good way of flowing that workload dependency to other projects.

Some possible solutions:

Do nothing

Projects which consume NuGet packages which use NET Maui will have to explicitly set the UseMauiEssentials property. This is a poor experience, especially because there won't be anything to help developers know they need to do this.

Use FrameworkReference to drive explicit workload opt-in

Maui essentials does use a FrameworkReference to bring in the Maui library, and this will already flow through packages and (I think) project references. We could add logic to the SDK (possibly coming from workload manifests) that recognizes that this FrameworkReference comes from a workload, and generates an error about how to opt in to the workload.

Move KnownFrameworkReference for Maui essentials into .NET SDK

The KnownFrameworkReference for Maui essentials is in one of the Maui workloads. We could move it to the .NET SDK itself, so you don't need to use the workload in order to consume the FrameworkReference. However, this would make it harder to version consistently with the rest of the Maui workloads. Also, while it would work for Maui Essentials, which only adds some APIs, it would not work for a workload which needs to include build logic (such as Maui.Core, I think).

New NuGet feature to support flowing workloads

NuGet currently flows FrameworkReference items to consuming projects. However, we can't use MSBuild items to enable workloads, we need to use properties (this is due to the multi-pass way MSBuild evaluation works, where items aren't evaluated until all project imports have been resolved).

NuGet could be updated so that if a project depends on a workload, the information about what property needs to be set would be included in the NuGet package, and NuGet restore would set that property in the .nuget.g.props file it generates.

/cc @dotnet/dotnet-cli @Redth @jonathanpeppers @eerhardt @davidortinau @mhutch

[eerhardt]

I don't know which option is best. I don't like the (3) "KnownFrameworkReference for Maui essentials into .NET SDK" option, as I think this goes against the spirit of a workload. But if that is the best way forward, I would be OK with it.

One piece of information I recently learned is that we have the https://github.com/dotnet/comet project, which not only needs Microsoft.Maui.Essentials, but also Microsoft.Maui.dll. Today it sets UseMaui=true in its .csproj and publishes a NuGet package: https://www.nuget.org/packages/Clancey.Comet. So I don't we can limit this problem to just Maui.Essentials. I think we need to support a general fix here.

[dsplaisted]

We discussed this in a meeting a couple weeks ago. We concluded that we can't and shouldn't flow workload MSBuild logic through NuGet. We can't because workloads may have PackageReference items or other logic that affects NuGet restore, so opting in to a workload after restore wouldn't always work correctly. We also think that probably something like opting in to Maui shouldn't happen implicitly based on what packages are referenced, you should have to explicitly opt in to it.

References to APIs via FrameworkReferences, on the other hand, should flow. Instead of moving the KnownFrameworkReference into the .NET SDK, however, we decided that it can go in the WorkloadManifest.targets and be included whether the workload is being used or not. That way for the Maui essentials scenario, referencing a NuGet package will be enough for those APIs to flow and work.

FYI @jonathanpeppers @Redth

[jonathanpeppers]

@dsplaisted so we could move the item group like this one:

https://github.com/dotnet/maui/blob/2b8deeea6423edab2a1ac451c41b0f826a6e082c/src/Workload/Microsoft.Maui.Sdk/Sdk/BundledVersions.in.targets#L46-L59

Here instead:

https://github.com/dotnet/maui/blob/main/src/Workload/Microsoft.NET.Sdk.Maui/WorkloadManifest.targets

Does it need to have a Condition at all? What prevents it from being added to every project type?

[dsplaisted]

The KnownFrameworkReference should be added to every project type. That simply adds it as an available framework to reference, the project won't actually reference the APIs unless there is a matching FrameworkReference, which would usually be added via one of the Maui workloads, or by flowing transitively through a project or NuGet package reference from a project that did use the workload.

So it should probably be without a condition.

You will probably need to change it so that the item declaration doesn't use properties such as _MauiRuntimePackVersion or MauiWorkloadTargetFramework, as those are defined in a .targets file that won't be imported if the workload isn't being used.

[jonathanpeppers]

@dsplaisted this seems to work as implemented here:

dotnet/maui#5429

[dsplaisted]

We hit a snag in this. The .NET SDK will download all matching KnownFrameworkReferences whether they are referenced or not, because they might be referenced transitively via a NuGet package. This means that adding the Maui Essentials KnownFrameworkReference to all projects will cause all projects to download the targeting pack, and likely run into restore errors during preview when it can't be found.

There is a potential NuGet feature that could resolve this: NuGet/Home#9937