How does workload versioning work?

[cosminstirbu]

I'm trying to understand how versioning works in the new "workload" world in .NET.

Can 'maui' workload be updated independently of .NET? Based on the docs docs.microsoft.com/en-US/dotnet/core/tools/dotnet-workload-install#results-vary-by-sdk-version it seems that workloads are "bundled" with .NET releases (major and minor versions).

And if they are indeed "bundled" together, does this mean that if maui needs to ship a hot fix, then it will be done by releasing a new .NET version (e.g., a minor version)?

Since dotnet workload list command doesn't output any workload version, it leads me to believe that the workloads and .NET versions are indeed "bundled" together.

[davidortinau]

This is how you select the version of .NET (and thus .NET MAUI): https://docs.microsoft.com/en-us/dotnet/core/versions/selection

.NET MAUI is an optional workload and those are associated to a specific version of .NET. Today, this is how versioning works. In the future some additional versioning information will hopefully be added to the dotnet workload list. Today you can see some versioning information by expanding the package dependencies in Visual Studio.

An update to .NET MAUI (hotfix) does not require an update to .NET although it might, depending on the nature of the fix. If we were to do an update without bumping the version of .NET, then you could update with the CLI dotnet workload update command. https://docs.microsoft.com/en-US/dotnet/core/tools/dotnet-workload-update

[yunusefendi52]

(I wonder whether #11206 is a partial solution to the problem.)

@MartyIX I really hope so, I tried download the nupkg and import sdk directly with versioning and it works

[svaldetero-envoc]

@davidortinau You say select the Maui version based on the dotnet sdk version, however I just experienced a new build failure in Azure Devops stating otherwise. I have a build from yesterday and a build from today that both download .NET Core sdk version 7.0.203. However when I get to dotnet workload install maui-ios, I get two different versions - yesterday: microsoft.net.sdk.ios version 16.2.2054, and today: microsoft.net.sdk.ios version 16.4.7054.

This wouldn't normally be a problem, however I now get this build error: error MT0180: This version of Microsoft.iOS requires the iOS 16.4 SDK (shipped with Xcode 14.3). Xcode 14.3 can't be installed on the macos12 image (which is macos-latest) and macos13 is barely available in public preview and not the default xcode installation. I have changed nothing in my code and my builds don't work. So it looks like my options are either:

1. try to pin the maui workload version to the previous one (maui-ios 7.0.81 -> Microsoft.iOS 16.2.2054)
2. Manually set Pipeline image to macOS13, add xcode select to 14.3, cross my fingers and hope that image is available and no software is missing

Is there a way to pin the MAUI version since that is the less risky approach? Or do I need to pin SDK to the older 7.0.202 (even though I've been building against 7.0.203 for a month)?

[MartyIX]

(I don't know the answer but FWIW main git branch contains

maui/src/Templates/src/templates/maui-mobile/MauiApp.1.csproj

Lines 59 to 60 in 1bbe79d

	<PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiVersion)" />
	<PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="$(MauiVersion)" />

introduced in #14770)

[hileyj]

@svaldetero I ran into this starting yesterday as well. To workaround for now, I am using option 1 that you suggested. Basically:
dotnet workload install wasm-tools maui --from-rollback-file https://maui.blob.core.windows.net/metadata/rollbacks/7.0.81.json --source https://api.nuget.org/v3/index.json
I'm also curious what the expectation is in this situation and what is the proper way to handle this.

[Hooterr]

I run into this issue as well. My project was building fine locally since I was on a slightly older version of .net 7, but the github actions machine resolved a newer version of MAUI resulting in a failure.

I can't say I understand this approach. It sounds catastrophically bad. Can my project update itself when I update VS Studio, when I install a new .net. version, when I use a different machine?? I've never seen anything like it before. This doesn't make any sense.

What if I have multiple projects on my machine, written for different versions on MAUI? One for .net6, one for .net7, one for .net7 but older version of MAUI. Do I need to reinstall workloads every time I open one of these projects?

At this point, the version MAUI might as well be bound to the current weather...

[durandt]

Related:

How do we know which MAUI Service Release (https://github.com/dotnet/maui/releases) is included or not in the current workloads?

Service Release 3 was released more than two weeks ago and as I understand it exposes CollectionView.Controller as internal so that Maui-CommunityToolkit may use it. But I have been unable to build Maui-CommunityToolkit's main branch for the past week or so due to the compiler refusing Error CS0122: 'ItemsViewHandler<ReorderableItemsView>.Controller' is inaccessible due to its protection level (CS0122) (CommunityToolkit.Maui).
Is there a way to see which workload versions contain which Service Release/MAUI version ?

(I found this earlier question but I do not find the answer satisfactory: https://learn.microsoft.com/en-us/answers/questions/947953/how-do-i-get-net-maui-service-releases)

@davidortinau

Update 1: I updated VS & workloads this morning (supposedly after Patch-Tuesday releases) and it fixed the Error CS0122-issue in Maui-CommunityToolkit. But I am still interested to learn more about the release process.

Update 2:
Before workload update:

Installed Workload Id      Manifest Version       Installation Source
---------------------------------------------------------------------
wasm-tools                 7.0.2/7.0.100          SDK 7.0.100        
maui-tizen                 52.1.0/7.0.100         SDK 7.0.100        
maui-maccatalyst           52.1.0/7.0.100         SDK 7.0.100        
maui-ios                   52.1.0/7.0.100         SDK 7.0.100        
maui-android               52.1.0/7.0.100         SDK 7.0.100        
maccatalyst                16.2.1024/7.0.100      SDK 7.0.100  

After workload update:

Installed Workload Id      Manifest Version       Installation Source
---------------------------------------------------------------------
wasm-tools                 7.0.3/7.0.100          SDK 7.0.100        
maui-tizen                 7.0.59/7.0.100         SDK 7.0.100        
maui-maccatalyst           7.0.59/7.0.100         SDK 7.0.100        
maui-ios                   7.0.59/7.0.100         SDK 7.0.100        
maui-android               7.0.59/7.0.100         SDK 7.0.100        
maccatalyst                16.2.1024/7.0.100      SDK 7.0.100        

The Manifest Version now seems to match the Maui Service Release version better.

[copang]

Hello,

I'm also wondering how the workload works, I'm using VS for Mac and just updated to version 17.5.2 with .NET SDK (Arm64) 7.0.202, but when I check again it seems it's still on version 7.0.200

In addition, I also see version 8 preview with lots of bug fixes, so to get these fixes I need to use version 8 right? So is version 7 still being updated?

[durandt]

After each VS-for-mac updated, I have been prompted by Visual Studio to install the workloads, although the installed version (7.0.59) was the same as previously. So it seems that VS-updates somehow require or trigger re-install of workloads. Would be nice to have that behavior documented too.

I hope net7 will continue to receive fixes for the whole 18months support period. I guess the release has been delayed a bit, Maui's releases don't match 100% Patch-Tuesday releases.

[durandt]

Fixes are applied to the 8.0-branch, but here you can see which fixes are being/have been backported to 7.0:
https://github.com/dotnet/maui/commits/net7.0

[RobTF]

Fixes are applied to the 8.0-branch, but here you can see which fixes are being/have been backported to 7.0: https://github.com/dotnet/maui/commits/net7.0

If some fixes are only going into .NET 8, doesn't this run counter to the LTS/STS support model? How do you reconcile the two?

[JoacimWall]

Hi
Testing the latest stable version of VS for Mac and has enabled the preview feature for dot net 8 pre 6.
I have installed the latest dot net 8 release and I can get I empty new project to build but as sone as try to build my MAUI project(works in dotnet 7) that is more complex I get strange errors.

So okej I go back to version 7 and wait for next preview but that is not working.

Is the dotnet 7 and 8 suposed to work side by side?
If yes then how? I have tested to disable the preview flag in settings and add the MauiVersion tag to the project file, but VS for Mac returns that it can only find the dotnet version 8 workload.

//Joacim

[DynConcepts]

Also having problems with workloads and versioning... I have 2 projects... Both are using .NET 8.0 but need different versions of workloads [in this particular case Aspire, but there are others]... so how do I open multiple terminal/command/powershell/visualstudio instances and have different versions of the workload(s) active?