How does updating of MAUI framework libs to a newer version works?

[MagicAndre1981]

How does updating of MAUI framework libs to a newer version works? In XF I can update the nuget package, compile and test if my apps still work. If I get issues I can undo the change without committing the changed csprojs. How does MAUI framework get updated? Only via new VS2022 update? What if I get a MAUI bug that blocks me? Restore my Windows to older restore point with older VS2022 and older MAUI version? And how do I know which MAUI version I compile my app against?

@StephaneDelcroix @davidortinau @PureWeen can anyone give an answer to this?

Originally posted by @MagicAndre1981 in #6730

[MagicAndre1981]

I migrated it to an issue as I never got a helpful reply in the discussions.

If MAUI Update are related to specific VS2022 updates, MAUI is dead on arrival.

[drasticactions]

MAUI is a dotnet workload component, along with the platform (iOS, Android, macOS, etc) SDKs. These are versioned internally but are not directly exposed to you. The idea is that you would always run the newest version of any given workload, and if you wanted to run specific versions, you would run a install with a given rollback JSON file.

But generally, you would either update by installing newer Visual Studio releases, which include workload updates. Or you would update via CLI with dotnet workload update.

If you would like to know my (personal, not speaking for this team) feelings about the workload system, please read this issue comment, #6082 (comment).

[MagicAndre1981]

thanks for the information @drasticactions . So the update issues from the previews will continue in each future update after GA and we users have no control over this mess, so MAUI is doa.

[holecekp]

This sounds really scary. My experience with Xamarin.Forms is that updating it to a newer version has always been a very risky step and it required a lot of testing but, at least, I had a full control over it. I could upgrade when I had time for the testing, and I could also downgrade easily if there was a major bug. Unfortunately, this was very often.

[MagicAndre1981]

This sounds really scary. My experience with Xamarin.Forms is that updating it to a newer version has always been a very risky step and it required a lot of testing but, at least, I had a full control over it.

I fully agree with you, but as you can see no answer from official MAUI team, they will simply ignore the update issues and claim that newest version is always the best even if it completely broken for us.

[MagicAndre1981]

@holecekp here is an example of an issue that happens because we have no control over the used MAUI version #7420 . It is so scary that MS ignored this disaster

[drasticactions]

@holecekp here is an example of an issue that happens because we have no control over the used MAUI version #7420 . It is so scary that MS ignored this disaster

To be fair about that specific issue, I believe it has more to do with VS tooling rather than MAUI itself (Remember that MAUI workloads are through dotnet itself). I sympathize with your sentiment, however. I would slightly disagree that was "ignored" as comments like mine above point to. There is a constant ongoing discussion about how to improve the workload system, both before MAUIs release and now. For myself, that includes things like proper versioning.

Again, I'm only speaking for myself, not any team.

[MagicAndre1981]

There is a constant ongoing discussion about how to improve the workload system, both before MAUIs release and now. For myself, that includes things like proper versioning.

this has to be done before releasing something as "stable". During preview phase I had 6 VMs running as updating VS previews always broke something about MAUI. And I simply expected that proper versioning is done before the release, but it looks like MAUI had to be released at BUILD 2022.

[holecekp]

I am mostly concerned how these two situations will be handled for MAUI apps in production:

• Reproducting crashes and other reported bugs - Imagine the following hypothetical situation. A user reports a crash in your app (or the crash is reported automatically by AppCenter of similar library). The problem is that the version has been released about a month ago and you are not sure which versions of MAUI had been used. With Xamarin.Forms, you would simply use git to checkout into the tag for the release for which the crash is reported. The correct version of Xamarin.Forms would be used because its version number is in files in the source control. You can simply try to reproduce the bug. With MAUI, if I understand it well, the situation is different. When you checkout into the version with the bug, the latest version of MAUI is used. So if the crash is specific to a certain version of MAUI you will not be able to reproduce it. The only chance is to guess, which version of MAUI could have been used for publishing that time, and try to create a rollback JSON file so that you would be able to make your code behave in the same way as your already published app. Is it correct? Maybe I have misunderstood how it works and maybe there is an easier way.
• Breaking changes in MAUI - Sooner or later there will be a breaking change introduced in MAUI. For example, there is currently a bug that bottom tabs are displayed when top tabs should be displayed and vice versa (Shell: Tabs are not displayed correctly in RC 3 (transparent controls, inconsistent behavior) #7033). Fixing it can be challenging because MAUI is not a release candidate any more and some developers could have started creating apps that will depend on the erroneous behavior and they simply use a XAML that positions the tabs where they want them. Now there are two options: 1) Leave the bug as it is forever, even if it is a breaking change compared to Xamarin.Forms and the behavior also depends on the used operation system. 2) Fix it in a future release of MAUI. This could create another problem because the developers that created their app with the current MAUI version will have probably a XAML in the Shell designed in the way that depends on the buggy behavior. Releasing a new MAUI version with the fix will be a breaking change for them. Even if they notice the change and modify their XAML to take into account the fix, there is still another problem. What if they will need to checkout an older version of their app in the git? They will run it and suddenly there could be top tabs instead of bottom ones, or vice versa, because they will checkout a version of their code with the XAML for the MAUI with the bug, but it will run on a newer version of MAUI without the bug.

Please, correct me if I am wrong. Maybe I have just misunderstood how it works and maybe there will not be any problem in either of these situation. Even if I understand it well, I will be glad if you share your ideas on how would you cope with these two situations in MAUI.

[dansiegel]

It seems like this thread is largely filled with people who are scared simply because there is some mystery around the toolchain... Hopefully this will help clarify some things for those who are a bit nervous. As a consultant, I can tell you that it is not at all uncommon for me to see people on old versions of Xamarin.Forms... But how do you pin your app to a specific version of MAUI? At first glance it may seem this is more difficult than it is, it just would be done differently.

First remember that MAUI is part of the .NET SDK. This means that if you have 6.0.100 installed you get the version of MAUI that was released with that release of the SDK... if you have 6.0.200, then you get that version of MAUI. The answer quite bluntly is as simple as controlling the version of the .NET SDK that your project is using. You can find a lot of samples of how to do this in various Open Source repos including Prism. You can also read more about this in the global.json docs.

{
  "sdk": {
    "version": "6.0.300",
    "rollForward": "disable"
  }
}

In short adding a global.json as shown above would pin your project to that exact version of the .NET SDK & MAUI. If you want to continue working on that even while the rest of the world is on .NET 8 you can. IMHO this ultimately is going to be a best practice for MAUI devs as it will ensure that you are consistently working against the same version of the SDK from one Developer machine to the next, and that your CI build is also using the correct version of the SDK to avoid any surprises.

I'd also like to address the unspoken fear. For those coming from Xamarin.Forms, if you've been around a while you've likely been severely affected at one point or another by updates to the native iOS/Android SDK's. The Version of Xamarin.Forms was built on an older one, or it is somehow different on your machine than it is on another developers machine or from the CI build host. It is really worth noting that as I understand it those iOS/Android SDK's are also part of the same .NET SDK which means that when you pin to a specific .NET version you're consistently getting the same native SDKs and version of MAUI everywhere you develop, build & publish. Hopefully this helps.

[MagicAndre1981]

@holecekp here is also an issue #7505 that shows errors after updating VS version and having a broken MAUI environment, but hey it is always our fault, we don't understand the glory workload system 🤦‍♂️

[mattleibow]

Just adding a note, I have a workaround: https://github.com/mattleibow/DuplicateEntryMauiTest/blob/main/Directory.Build.targets