Make MAUI into 1 workload and lots of NuGets instead of a full workload

[mattleibow]

Description of Change

This PR is to attempt to move towards a world where most MAUI bits are actually nugets.

We may require this in order to work with .NET 7:

• Add a condition to skip the AutoImport.props #11665
• Prepare MAUI to support building with NuGets #11946

Once this is merged you can still use all the same things as <UseMaui> will just now install nugets instead of use workloads. If you want to update the version of the nugets, you can just use the nuget package explorer - or use <MauiVersion>.

The only real fundamental change is that .NET MAUI is now entirely (almost) in NuGet packages instead of partially in nugets. This allows for cleaner updates. The aim of this PR is not to do away with workloads as they still offer several features we like, but rather move code that CHANGES into nugets. So we still want the magic of <UseMaui> or <UseMauiCore> but we also want to ensure that maui is determined by the nugets you install, not the workload you happen to be on.

Tasks:

• Move all assemblies into nugets (core, controls essentials)
• Move all targets into nugets (resizetizer and xamlc)
• Make sure we still support net6
• Write some docs on how things work

Testing

There are 2 ways to test this PR:

1. Remove all Microosft.Maui.* from your NuGet caches (or just clear it all)
2. Use the local .NET SDK for everything:
   1. Run dotnet cake --target=VS --pack --sln="/path/to/your/solution.sln"
   2. The IDE will launch and you can run using F5
3. Use a global version of .NET MAUI (only supported on 7.0.58 and later)
   1. Download the NuGet artifacts from this PR or CI branch
   2. Extract the artifacts into a folder and add an entry in your NuGet.config to this folder (either in your solution directory or in VS)
   3. Open the project that you want to test with in the IDE
   4. Add the special property (just a temporary property until this PR is merged):

      <PropertyGroup>
          <UseMauiNuGets>true</UseMauiNuGets>
      </PropertyGroup>

   5. Add the new nugets to your project:

      <ItemGroup>
          <PackageReference Include="Microsoft.Maui.Controls" Version="VERSION_FROM_CI_HERE" />
      </ItemGroup>

   6. Due to Microsoft.Windows.SDK.BuildTools is missing buildTransitive microsoft/WindowsAppSDK#3251 you will also need to add the Microsoft.Windows.SDK.BuildTools package to windows:

      <ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">
          <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.755" />
      </ItemGroup>

   7. Run using F5

[jonathanpeppers]

Does anything test that net7.0 projects continue to work? What about net6.0?

[mattleibow]

Thanks for all the reviews @jonathanpeppers ! I did observe the crazy things again with the IDE and the capabilities. I think I found out where/what caused the issues, but we are safe in this PR. I can reproduce and then fix the issue reliably, so I am almost confident it is not going to cause issues...

[yunusefendi52]

I have a couple questions for this:

1. Can I use MAUI without downloading the workload? like the way Xamarin.Forms used to
2. Is this also going to make MAUI supports any underlying dotnet ios/android version? Current version (7.0.59) needs dotnet ios 16.2 but if I use dotnet ios 16.0 it wouldn't work because MAUI needs 16.2.
   Xamarin.Forms doesn't really care what Xamarin ios/android version you use technically, if MAUI doesn't support that then I think it's still a stepback. I'd say dotnet workload system is a stepback generally

[mattleibow]

@yunusefendi52 to answer your question, almost.

TL;DR

No, we still need workloads. This is phase 1 of reducing workload version restrictions. This PR makes it so you don't need to care what version you have installed as you now use nugets for that.

Long answer

This PR does not aim to make it workload-free as we do get some nice things. However, Windows and the IDE need more attention. One of the core issues is that the IDE decides what menu options and toolbar actions to do based on project capabilities - and these cannot be in nugets.

In the old world, Xamarin.Forms had separate projects with project type GUIDs to do this. In .NET 6+ this is now the responsibility of the workloads. This allows actions to be influenced by a SDK outside the IDE.

During the hacks I was doing recently, it appears that because workloads are just a "wrapper" around the existing SDK importing and things like that - think the MSBuild.SDK.Extras if you are familiar, we can potentially have our own SDK and then will not need workloads.

But, the core goal of this PR is to get all changing logic into nugets, so almost we don't need workloads. What this presents itself after the merge of this PR is that it won't matter what workload you have installed because there is no changing code in there. If you want a different maui version, either use MauiVrsion - or just select the version using the NuGet package manager.

[Eilon]

Here's what I've done:

• Run the branch locally on a Windows machine to run the Windows and Android samples in the MAUI solution
• On the same machine, I created new MAUI / MAUI Blazor projects and run them with this change
• Did editing in VS, debugging, etc.
• Reviewed the code changes in the PR
• Inspected the contents of the built NUPKGs

I do have two areas of unknowns/concerns that I think need to be addressed at some point:

1. There is a very long VS hang after debugging the Controls Sample app on Windows in the MAUI solution. On a very high end dev machine VS hangs for 2-3 minutes and the VS UI is "ghosted" (unresponsive, not rendering). It does eventually wake up. This doesn't happen with Android. Running without debugging is not affected. This has been reported to VS. I think this could make working in the MAUI solution very difficult. I'm not sure if this affects less complex solutions.
2. While I verified that the built NuGet packages indeed contain what I expected them to contain, I am not able to verify whether this change would in fact enable customers to pick their MAUI versions, do various side-by-side scenarios, etc.

In totality, this PR looks good, so I sign off.

[jonathanpeppers]

I'll finish reviewing next week. Mainly just want to read the files GitHub says changed since last time.

Is there any concern to merge this prior to branching .NET 8 Preview 1? Maybe we should merge right after branching is done?