Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

[Enhancement] Port Xamarin.Forms 5 to .Net 6 Runtime, if possible #14829

Closed
juwens opened this issue Nov 3, 2021 · 23 comments
Closed

[Enhancement] Port Xamarin.Forms 5 to .Net 6 Runtime, if possible #14829

juwens opened this issue Nov 3, 2021 · 23 comments

Comments

@juwens
Copy link

juwens commented Nov 3, 2021

Summary

I strongly wish, that XF 5 will be ported to .Net 6.
Independent of the ongoing MAUI Net 6 project. It's gonna take a long time, until MAUI will be in an usable quality.

API Changes

none

Intended Use Case

Beeing able to use more NuGet Packages and Libraries.

@jfversluis
Copy link
Member

It's gonna take a long time, until MAUI will be in an usable quality.

I'm curious, what makes you say this?

@juwens
Copy link
Author

juwens commented Nov 4, 2021

It's gonna take a long time, until MAUI will be in an usable quality.

I'm curious, what makes you say this?

Maybe i'm too pessimistic, regarding the last years with MS tech stack.
But, but when is see the 3200!!! open bugs in XF, combined with my professional XF 5 experience, which was sometimes pretty rough.
Don't get me wrong, i like the .Net Stack (a lot), but in my experience, XF is of a lot worser quality, compared to the dev experience you get with WPF. And i don't see any significant bugfixes in XF 5.

And to come back to the question.
Based on that experience, i suspect the release of MAUI to be VERY rough.
And the migration of an existing XF 5 Lob application for Andoid, iOS and! Windows, even rougher.

I'll be a very happy dev, if they proof me wrong :-)

@jfversluis
Copy link
Member

jfversluis commented Nov 4, 2021

Thanks for sharing!

I don't really see how the number of open issues correlates to the quality. If you look at other libraries of this scale they have a same number, if not more issues as well. Issues are not necessarily bugs. Should we have done a better job at managing those issues? Probably, but I don't see why that means anything in terms of quality here.

There have been rough times for Xamarin.Forms for sure. I think one of the reasons here is that we had to be backwards compatible all the time. We now have broken free from that, which definitely makes things easier. Personally, I think Xamarin.Forms 5 is pretty good, and the good news is .NET MAUI will be based on that exact code.

Sure, .NET MAUI is rough right now. But in reality, I think .NET MAUI itself isn't even too bad. There is many factors that influence this right now: a new (preview) version of Visual Studio, a completely new product Windows App SDK that we want to use, the tooling inside of Visual Studio that makes .NET MAUI a breeze to use. All things that really have to work together in order to make it a pleasant experience. We realize we're not there yet, hence the push back of the date to make .NET MAUI generally available. We don't want to give you something that is rough, we want to delight you from day one.

I understand where your pessimism comes from, although I'm sad that you see it this way. Only thing I can say is that we are working hard to not let that happen. But again; thank you for sharing this open and honest opinion, I appreciate it.

As for your request, I don't think this will happen. If it's something you really want it shouldn't be too hard to do yourself, but our bet is on .NET MAUI. Xamarin.Forms is in maintenance mode. We will keep stabilizing it and making it the best version of Forms out there while .NET MAUI is ramping up, but if you want to leverage all the shiny new things that will have to be in .NET MAUI.

Looking forward to making you a happy developer in the near future!

@lassana
Copy link

lassana commented Dec 7, 2021

.NET6 support would simplify upcoming migration to a new stack.

I had a quick look at .NET MAUI and it looks different from Xamarin.Forms. To my knowledge no migration toolchain has been announced so far, so I expect that manual migration to MAUI will take us months not weeks. Luckily there is at least support for existing X.F renderers and effects.

We would like to be able to start using .NET 6 and continue to use Xamarin.Forms. This topic wouldn't be an issue if .NET 6 was binary compatible with old Xamarin. Unfortunately that's not the case.

@jfversluis
Copy link
Member

I had a quick look at .NET MAUI and it looks different from Xamarin.Forms. To my knowledge no migration toolchain has been announced so far, so I expect that manual migration to MAUI will take us months not weeks. Luckily there is at least support for existing X.F renderers and effects.

That sounds you have had a too quick look. What looks different according to you between .NET MAUI and Xamarin.Forms? The APIs are exactly the same minus a few renames. Migration can be done through the Upgrade Assistant so no manual migration required and that certainly shouldn't take months, what am I missing here? :)

@lassana
Copy link

lassana commented Dec 15, 2021

We, as Xamarin.Forms developers, depend not only on X.F but on other projects as well, e.g. Mvvmcross, Telerik, Syncfusion, Acr.Userdialogs, etc. Lots of them. Some projects have already started their way to .NET 6 / MAUI, but migration for some others will need to be done by us. Migration is not just replacing Xamarin.Forms.* namespaces with Microsoft.Maui.*. Even migration from X.F 4.8 to 5.0 was longer than we expected as it broke several hacks workarounds™️ we had.

Our ideal .NET 6 / MAUI migration path would be:

  1. Start targeting .NET 6; modify app sources and msbuild tasks if needed
  2. See if there are any runtime issues that prevent us from using .NET 6 in production
  3. If not, perform migration to MAUI

If Xamarin.Forms team decided not to support upcoming .NET 6 runtime, this migration path doesn't make much sense. We will evaluate the possibility of doing our own .NET 6 X.F builds but I doubt we are going to do so. Frankly speaking, we don't have much interest in maintaining the project that even Microsoft doesn't want to maintain.

@GalaxiaGuy
Copy link
Contributor

@jfversluis I'm in a very similar position to @lassana.

I have a large Xamarin code base that is mostly not Forms, but does include an increasing amount of embedded Forms views.

Being able to update to .Net 6 separately from upgrading Forms to MAUI would make things a lot easier.

@juwens

This comment has been minimized.

@jfversluis

This comment has been minimized.

@jfversluis
Copy link
Member

Alright, at least let me reopen this and have a little discussion here. What am I missing that .NET 6 support will bring you in this case?

I see a main reason is the NuGet packages and libraries. But if you want to use them, they still have to be recompiled against .NET 6 before you are able to use them, right? And chances are that they will take that opportunity to rewrite the library to .NET MAUI and thus chances are small there will ever be any library that supports Xamarin.Forms on .NET 6. Or am I missing something?

Also, I understand that upgrading a runtime to a major version can be scary, personally I feel that upgrading .NET versions typically don't have a lof of breaking issues? And be aware that this will be on a yearly cadence now, if you want to keep all the libraries and all the things that you use to keep upgrading so you can see if it's reliable each year, I think that will be one hell of a job.

The only thing that personally worries me, and I didn't look into it yet, is that Xamarin.iOS will go to .NET 6, so if there is any new iOS feature we need (which we will), then we still have to update for .NET 6. I was going to discuss this internally even apart from all this, so maybe I was very mistaken about all of this and we will still have to do this and everyone will be happy.

Like I said, let me reopen this one so we can coordinate from here. Please add anything to the discussion here (in a civilised way) and I will keep you updated on what I find out from my team :)

Thanks for all your input so far, this really helps!

@jfversluis jfversluis reopened this Jan 2, 2022
@jfversluis
Copy link
Member

jfversluis commented Jan 3, 2022

So, I talked to some of our team and my initial thought was right: we're not going to do a .NET 6 version of Xamarin.Forms.

Let me see if I can go into some things why. First: because of multiple reasons, it's a big effort on our part. Now, we don't mind doing work, but as you might be able to tell we already got enough on our plate with keeping the lights on for Xamarin.Forms as well as getting .NET MAUI on the road. Given the effort and the timespan of Forms, that is not really worth it. Also, there will probably also be people who want to/have to stick to pre-.NET 6 and now suddenly we have to maintain a Xamarin.Forms net6 and a Xamarin.Forms pre-net6 version with all of our fixes. As much as I want to make everyone happy, it's not feasible.

Additionally, we are invested in .NET MAUI and are convinced that is the way forward. If we would now invest in a .NET 6 version of Xamarin.Forms, that would send out a wrong signal. We're trying to wind down Xamarin.Forms and invite people over to .NET MAUI. Creating a .NET 6 version of Forms could be perceived as that support being prolonged and people then wanting even more support going into .NET 7 at some point and from there we're stuck in an infinite loop :)

As for the third-party library perspective; I still don't really understand how you see this happening. As I already mentioned in my previous comment; I don't see a lot of library maintainers going to create a .NET 6 Xamarin.Forms version. They are more likely to transition to .NET 6 and in that process shift to .NET MAUI as well. If we were to create a .NET 6 Forms version we would also put pressure on those library maintainers to also create 2 versions of their library, or even 3: a Xamarin.Forms pre-.NET 6 version, a Forms .NET 6 version and a .NET MAUI version. To be honest, we don't want to do that to our community.

Maybe I'm not understanding you correctly, but I don't think all the plugins that you're using will be willing and able to make a shift like this. And because of that the scenario that you're talking about here (a Xamarin.Forms .NET 6 version) is not likely to happen even if we would make Xamarin.Forms compatible. Then Forms would be compatible, maybe some libraries will follow, but I'm sure that some won't make their library compatible and then we still didn't win anything, right? At this point we've gone through a lot of effort, but people still won't be able to transition their Forms app to .NET 6 because libraries they depend on won't be available.

What I do see happening is a lot more frustration on all sides because of the added burden to maintain all kinds of different versions both for us (Xamarin.Forms) and the library maintainers (if they feel obligated to their users to make a Forms .NET 6 version) and then on your side, the consumer, because not everything is compatible and you still can't convert your Xamarin.Forms app.

Then the last thing I see is the fear of a new major .NET version. I kind of understand that, new versions can be a bit daunting, especially if it's the main framework that is updating to a new major version. On the other hand, I think the risks on that side are pretty low and you still have the ability to test it in all kinds of ways, for instance with spinning up a net .NET MAUI app and start porting some things over that are important to you. And .NET 6 is out now for a good couple of months and without any major issues as far as I know, but what I'm trying to say is: there is already a lot of experience from different angles and people out there that you can use to your advantage.

I myself did mention Xamarin.iOS moving to .NET 6, but they will follow the same path as Xamarin.Forms; they will be in maintenance mode so we get all the latest iOS updates from them, can use that in Xamarin.Forms and for iOS for .NET they will be moving to .NET 6 where the future will be.

I wish I had better news for you, but I think it's important to be clear that this is not going to happen so you can start making plans based on that information. If there is anything I can help with in that regard feel free to reach out either somewhere publicly (here or on Discord) or privately through email or any channel you can find me on.

Thanks!

@juwens

This comment has been minimized.

@jfversluis

This comment has been minimized.

@Eli-Black-Work
Copy link

@jfversluis I think that perhaps a main issue is that .NET 6 has been released, but MAUI isn't yet ready (Microsoft's documentation encourages people not to use MAUI for production apps).

This means that when writing a generic (non-Forms) NuGet package, we need to choose between having the package target one of these options:

  • .NET 5 (EOL in May)
  • .NET 6 (Xamarin users won't be able to use the package)
  • .NET Standard 2.0 (Limits what features the package has access to)

If Xamarin supported .NET 6, then the choice would be much simpler: Have the NuGet package target .NET 6.

@jfversluis
Copy link
Member

@Bosch-Eli-Black thanks for your input! I understand the situation, however I don't think it changes much in terms of a solution. That one NuGet will then be compatible, a lot of others won't be. That means that there is a good chance that effectively you still won't be able to use a Xamarin.Forms app because one or more of your dependencies isn't available for .NET 6 Forms.

Microsoft's documentation encourages people not to use MAUI for production apps

Which is always the case for previews from any vendor I would think. However, release is now set for Q2 2022, which should be right around the time that .NET 5 support stops. While not encouraged, there is also nothing stopping you from already starting to build with it and as soon as it goes GA, release your app then. And ultimately, you are the only one that can decide if .NET MAUI is in a state that you can use. I know for a fact that there is at least 1 .NET MAUI app already out there.

Again, I understand your side, I hope you can also our side of things. Like you said; .NET 6 is there, .NET MAUI isn't. Adding another flavor of Xamarin.Forms in the mix here for us to maintain isn't going to help move things forward quicker. If anything, it will only be an added effort that probably slows all the rest down. That is the trade-off we have to deal with and at this time we don't see the added value outweigh the gained benefit here, that is why we have made this decision.

@Eli-Black-Work
Copy link

@jfversluis Thanks for the reply 🙂

I'm not sure I'm understanding this sentence:

That means that there is a good chance that effectively you still won't be able to use a Xamarin.Forms app because one or more of your dependencies isn't available for .NET 6 Forms.

I thought that NuGet packages used in Xamarin apps were targeted to .NET Standard 2.0, which could be consumed by .NET Framework, .NET Core, and .NET 6 apps.

Thanks! 🙂 I'm coming at this from the perspective of a NuGet package author, so I'm a bit unfamiliar with how Xamarin works in this regard.

@jfversluis
Copy link
Member

jfversluis commented Jan 10, 2022

All NuGet library maintainers will have to recompile their libraries to make it .NET 6 (Forms) compatible as well. And I'm fairly sure that there are libraries out there that still work, but are no longer maintained and/or libraries that will port straight to .NET MAUI and not bother with a .NET 6 version of Xamarin.Forms. For libraries I see a couple of possible reasons for not wanting this:

  • We don't want to pressure our library maintainers into doing more work. Because if we as Forms give the signal that we will now have a .NET 6 Forms version, there will be some maintainers who are going to be willing to serve the community (which is awesome!) so it's a bit of self-protection for them here as well. We're already giving them enough work with pivoting to .NET MAUI;
  • There are maintainers working with us already to port to .NET MAUI, I would be surprised if they were now going to create some intermediate version as well. And again; we would be putting more pressure on them by maintaining an additional version, because we and they can't suddenly drop pre-.NET 6 Forms as there will be also people not willing/able to make that step (yet);
  • There are libraries that are simply no longer maintained but still widely used. These are now suddenly unusable.

I think for a lot of app builders they rely on libraries and if even just 1 of them isn't compatible that will be blocking for them to move forward to a .NET 6 version. If a package is popular enough then people would maybe step in to fork it with all the confusion that comes with that.

Additionally, one thing I didn't even mention before but comes to mind with you mentioning .NET 5 EOL, if we were to upgrade to .NET 6, people could then go make a case (which wouldn't even be that weird) that we should follow (at least) the .NET 6 EOL date and suddenly we are supporting Forms a lot longer than we originally anticipated on which is also not something we want to do. And maybe at that point people still aren't ready because of whatever reason and are asking for .NET 7 support and we can keep going and going until forever :)

We believe .NET MAUI is the way forward and we will support Xamarin.Forms for a good period of time so that people will have enough time to transition, that includes bugfixes and stability fixes and everything we need to do to keep it compatible with new iOS, Android and UWP versions. Unfortunately it doesn't include .NET 6 support.

@Eli-Black-Work
Copy link

@jfversluis Ah, I think I understand! 🙂 You're saying that NuGet packages that target .NET 6 and don't use Xamarin.Forms code (such as our NuGet package) would not need to be recompiled for a (theoretical) .NET 6 Xamarin.Forms, but any NuGet packages that included Xamarin.Forms code would need to be recompiled for .NET 6 Xamarin Forms. Did I get that right? 🙂

@jfversluis
Copy link
Member

I think that sums it up nicely!

@Eli-Black-Work
Copy link

Okay, thanks, that makes sense! 🙂

@mattkanwisher
Copy link

I had a quick look at .NET MAUI and it looks different from Xamarin.Forms. To my knowledge no migration toolchain has been announced so far, so I expect that manual migration to MAUI will take us months not weeks. Luckily there is at least support for existing X.F renderers and effects.

That sounds you have had a too quick look. What looks different according to you between .NET MAUI and Xamarin.Forms? The APIs are exactly the same minus a few renames. Migration can be done through the Upgrade Assistant so no manual migration required and that certainly shouldn't take months, what am I missing here? :)

Upgrade assistant is beyond broken, and isn't even half written for Xamarin -> Maui upgrade. Its a joke there are all these videos, but there is barely any code for the Maui upgrade, and its broken on install.

@jfversluis
Copy link
Member

@mattkanwisher sorry you feel that way, make sure to make your feedback known there. In all honesty, I don't know if I would use the Upgrade Assistant. Migration shouldn't be too hard and I am rather in control of all the steps myself anyway. But it's a tool that can definitely be useful to people.

@beeradmoore
Copy link
Contributor

@jfversluis I am somewhat confused here and maybe you can help clear this up. This is 100% me not understanding this part of .NET correctly and am not sure if anyone else above is in the same boat. Will lay my understanding out in dot points, can you let me know where I am mistaken.

  1. If I use Xamarin.iOS and target xamarinios10 it will use the mono runtime on device
  2. If I use Xamarin.iOS but target net6.0-ios (soon to be net7.0-ios) I now get the .NET runtime and the additional performance improvements that come with it
  3. (Same as above, but for monoandroid10.0 and net6.0-android)
  4. XF is a netstandard2.0 library
  5. net6.0-ios/android can run netstandard2.0 libraries
  6. XF can run net6.0-ios/android

I assume 6 is incorrect otherwise this wouldn't be an issue. I feel confident with 1-3. I think it is the 4-5 where things are not making sense to me.

If it is simple enough could you explain one part of what would need to be ported so we can get an idea of why its not going to happen. Would help me understand that as from above I thought it should just work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants