Side by Side MAUI possible?

Jim Borden 20

I am getting increasingly aggravated and defeated by this new distribution method. Basically from what I can tell, every release of the .NET SDK brings with it a new version of maui workloads that need to be installed via dotnet maui install / update / whatever. These, however, appear to be global and destructive so that while you can install any number of SDKs side by side, maui workloads are always overwriting each other. Here is where that becomes terrible:

My organization expresses a desire to maintain compatibility through patches on a given release line as we are developing an SDK rather than an app. For example, say we have 3.1.x which was released before .NET 7, and then 3.2.x that was released after .NET 7. 3.1.x is deploying for .NET 6 targets (yes I know they are out of support, but the stance is that we don't want to force our users to upgrade .NET versions just to get a fix of a given line).

However this seems just needlessly and aggressively difficult to achieve. Upgrading Visual Studio itself upgrades the .NET SDK, which for all intents and purposes bans you from building for a .NET 6 target with MAUI. Errors will come with things like "Microsoft.iOS references System.Runtime 7.0.0 but the build found 6.0.0". Is there any sane way to accomplish this or do we have to give up and force users to upgrade every year even to pick up things like a security fix?

What I want is a way to be able to build both (for example) net6.0-android and net7.0 android on the same machine without having to go through an enormous song and dance. I don't necessarily mean that the .NET SDK has to continue doing so, but can't I have, for example, 7.0.1xx and 7.0.4xx side by side, each with their own versions of the maui workloads?

Leon Lu (Shanghai Wicresoft Co,.Ltd.) 71,591 Reputation points Microsoft Vendor

2023-08-25T05:45:43.5+00:00

What I want is a way to be able to build both (for example) net6.0-android and net7.0 android on the same machine without having to go through an enormous song and dance

If you want to change .NET 6.0 to .NET 7.0, please open the .csproj file, change all of 6.0 to 7.0.

for example, 7.0.1xx and 7.0.4xx side by side, each with their own versions of the maui workloads?

Based on your need, I use global.json to set specific .NET version(As note, this way will be changed .NET sdk version globally and you need to downalod this SDK before you used), for example, My current .NET SDK version is 7.0.304, I set .NET SDK version to 7.0.306 by dotnet new globaljson --sdk-version 7.0.306. Then I can run my MAUI application by SDK 7.0.306(Before running application, please clean and rebuild your project).
Jim Borden 20 Reputation points

2023-08-26T01:11:44.0366667+00:00

Even if I specify a version of the .NET SDK to use, the installed workloads might not be compatible with that version. What I am really after is the equivalent of maui workloads in global.json (maui-ios and maui in particular). For example, if using maui 7.0.92, building for net6.0 is not possible because the assemblies inside all link to System.Runtime 7.0.0.

Accepted answer

Bruce (SqlWork.com) 60,361 Reputation points

2023-08-25T16:17:11.11+00:00

While net6 and net7 run side by side, patches don’t. You should have no issue building and release a net6 and net7 version. .net patch releases are not supposed to have any new features, or breaking changes, only bug fixes.

the workload is visual studio tooling to build, debug and publish. A new net version requires a new workload. this workload should have no effect on the previous version.

now Maui is often used for mobile development. Here is where you may have issues. The native mobile sdks and tools are not on the Maui release schedule. A mobile sdk change may require a new Maui release to support. A change in mobile builds tools may require a new release of the visual studio workload.

for example a new iOS release requires a new Xcode release. To support this a new new Maui release is required. Unlike android, iOS users update pretty quickly, so you will need a new iOS release pretty close to iOS release date.

if you are supplying a sdk, you will probably need to support pre-releases. As users can install beats versions. Say you now have a net6 and a net7 release. You will need to retest as each sdk as new mobile o/s are released, and have a quick release cycle for fixes.

a practical issue you will have is keeping the Maui workloads current enough to support new mobile releases.
Please sign in to rate this answer.
Jim Borden 20 Reputation points

2023-08-26T01:09:35.1633333+00:00

The bigger issue in my mind is not keeping maui workloads up to date. That is relatively easy. The problem comes in keeping the OLD ones around. From what I can tell, a workload (in particular for Apple) is a marriage between a given .net runtime version and a given Xcode version. It's so complicated to me that I struggle to even put it into words. Either I have the wrong Xcode version and I get an error because the maui workload is demanding a certain version, or the maui assemblies like Microsoft.iOS.dll are linking with the wrong System.Runtime (7.0.0 vs 6.0.0) and are unusable.

I am trying to instruct a coworker on how to build one of our previous lines, which is net6.0-ios14.2. So the first step, installing Visual Studio 2022, immediately installed .NET SDK 7.0.400 which pulls in the MAUI workload 7.0.92 which links with System.Runtime 7.0.0 an and cannot be used for net6.0. MAUI workloads and .NET sdks seems to be independent and a rollback file can specify a combination of the two which is even more confusing because sometimes those combinations don't exist? And then on top of that there is the independently moving underlying ios workload which. It really seems like Microsoft is pushing us to drop support quickly every year for .net runtimes in MAUI.

You are correct about the fast uptake in iOS adoption, but this poses another problem. Since .NET 6 will never be updated again, eventually I believe that .NET 6 will be completely unusable then the underlying version of Xcode it uses is no longer allowed. One suggestion I have received is to create a VM with frozen tools for every version of the .NET runtime I need but this seems so heavy handed. What I'm really after is a way to be able to quickly specify all the versions of tools I need to use to successfully build, without having to go through a system wide install of workloads to accomplish it. It sounds like this is not possible, because workloads are always overwriting into a system wide location. It sounds like way too much of a hassle to be honest and instead I might just push back and say "we cannot continue to support .net 6, sorry" and then repeat the same line for .net 7 at the end of this year, and then the same line for .net 8 at the end of next year.

Bruce (SqlWork.com) 60,361 Reputation points

2023-08-30T15:54:31.7966667+00:00

With iOS typically a new o/s release requires a new version of Xcode. This new Xcode supports older code bases.

but the Maui build chain builds Xcode projects, files and calls Xcode. This often is not compatible with a new release of Xcode. While you can install multiple versions of Xcode, they have different names.

you probably will need multiple Mac build machines, setup for each environment you want to support.

you will also need to decide how long after Maui support ends you want to support updates to your sdk. For instance, Maui for net 6 is no longer supported by Microsoft.
Sign in to comment

1 additional answer

Jim Borden 20 Reputation points

2023-08-26T01:22:04.4166667+00:00

I just thought of something after typing this that goes against the way I understand .NET SDK but sort of makes sense given all these restrictions. To continue building for .NET 6 MAUI, am I required to use the .NET 6 SDK? This is a break in behavior from the routine whereby a newer SDK can build for an older runtime.
Please sign in to rate this answer.
Bruce (SqlWork.com) 60,361 Reputation points

2023-08-27T01:30:05.0433333+00:00

you are correct. the .net core runtime is side by side for each version. only patches: major.minor.patch are update in place. actually the patches are really side by side, but the default behavior is to use the highest patch number. but you can lock your app down to particular patch. unlike 4.*, there is no support for overriding version binding.

.net core has a support cycle. net 6 (a LTS version) support ends November 12, 2024, while net 7 support ends earlier on May 14, 2024

.net core LTS version are supported 1 year after the next LTS release which are scheduled for every 2 years. a non LTS version is supported for 6 months after the next release. the next LTS is net 8 in Nov this year. so basically LTS versions are supported for 3 years after release. non LTS version are supported for 18 months after release.

now Maui (probably due to mobile support) has a different life cycle. Maui versions are tied to .net core framework version, but have different lifecycles. For example, while net is is supported to Nov, 2024, Maui 6 is already out of support (need May 8, 2023). Maui 7 support ends with Net 7 support (May 2024).

this means you probably need to stay current with the point releases.

another concern is Mobile O/S support. Maui 8 will support IOS 15 (in beta, released in Sep), but it's unclear whether Maui 7 ever will.

Jim Borden 20 Reputation points

2023-08-29T23:02:25.1833333+00:00

Ok I think this is evidence that I need to keep .NET 6 SDK installed in order to continue building (out of support) .NET 6 targeted MAUI libraries / apps. I will use this information going forward as well for when .NET 7 goes out of support.
Sign in to comment

Share via

Side by Side MAUI possible?

1 additional answer