Xamarin.forms: Uwp Xamarin.Forms.Shell

[allessandrosj]

Uwp Xamarin.Forms.Shell does not work correctly in uwp, the same way it works on android and ios

[pauldipietro]

Shell support is only provided for Android and iOS at this time. We are continuously evaluating feedback regarding potential future UWP support and will provide more information in the future as it becomes available.

[jcmontoya]

I normally use iOS and Android for my phone users and UWP for my tablet and desktop users. So having UWP support will be very important to keep windows users engaged.

[TiBall]

What?? MS is really ditching their own platform. This is sad to hear!

[Juansero29]

Isn't there any visibility on when UWP support will be given? Or has the decision already been made?

[snow-jallen]

Shell support for UWP - please!

[akuehntopf]

I'd also like to see UWP support for the Shell.

For my company UWP is quite important because our customers use Windows Tablets in combination with some Android phones to get their work done. We won't be able to migrate to Shell if UWP support is missing.

[dan-meier]

Agreed -- UWP compatibility allows me to bake in Windows tablet capability with my mobile implementation. I'd have to code this completely separately without it. Yuck! UWP compatibility is a must-have!

[cbradbaer]

I don't know if it makes sense, because I have not used Shell yet. But maybe there is a way to use all other elements of the App (besides Shell) for a UWP implementation. After all using TabbedPage and MasterDetailPage would achieve the same thing, it seems.

[JakePorter05]

I also would vote for the ability to use UWP with Shell.

[dgerding]

UWP please... or at least some flavor of Microsoft UX API we can depend on for a few years. This approach of "we'll let you know if we might support it later" is just mean.

So, yes, UWP or whatever will support it but more importantly: A COMMITMENT TO WHEN WE'LL KNOW IF OR WHEN.

Can't move to Shell without that certitude.

[melihercan]

Not only UWP but MacOS as well please.

[Mephisztoe]

I don't know if you realized that UWP is not only a platform that is still widely used by developers, but also the fastest way to get Android and iOS based XF apps up and running. Because - in comparison - the emulators provided for both the Android and the Mac world are freaking slow, prone to problems and let's not talk about the horrible certification experience or still being forced having a real Mac around, shall we? So even though it cannot replace developing on the real thing after all, an UWP app increases developer productivity by offering a fast, easy and comprehensive way of getting… things... done. And then: Do what it takes to get your app up and running on iOS and Android as well.

So will you please add shell support for UWP?

[PureWeen]

https://github.com/xamarin/Xamarin.Forms/pull/6015

[mzhukovs]

Agree with @Mephisztoe it really is a great productivity tool, and of course the option of actually making the app available for Windows is a nice plus too :)

[drchilds]

Please don't relegate Xamarin.Forms to mobile platforms only. I'd like to see continued support for UWP especially, but also WPF and GTK#.

[nitrouscutter]

So basically anyone who has an app that is cross platform for all three platforms in Xamarin Forms right now cant update and use these features. If future development on Xamarin Forms for UWP wont happen why not just remove UWP from the cross platform list?

[GalaxiaGuy]

Different platforms will always have different priorities. After all, you said "all three platforms", not "all seven platforms".

[nitrouscutter]

@GalaxiaGuy that's correct, I did say all three platforms considering if I said seven platforms I would be making up imaginary platforms. According to Xamarin.Forms documentation:

Xamarin.Forms
Xamarin.Forms exposes a complete cross-platform UI toolkit for .NET developers. Build fully native Android, iOS, and Universal Windows Platform apps using C# in Visual Studio.

[GalaxiaGuy]

And on the readme it says:

Xamarin.Forms provides a way to quickly build native apps for iOS, Android, Windows and macOS, completely in C#.

That doesn't mean it doesn't also support GTK, WPF and Tizen.

I agree that those platforms are probably less important than UWP, but there are a lot of people who think that UWP is less important than iOS and Android.

I generally agree with the sentiment though, and I'm having to ignore newer features myself because of them not being on UWP.

[JeroMiya]

FYI, unless I'm reading the release notes incorrectly, it looks like there's a ShellRenderer implementation for Tizen in the 4.1 preview. No mention of UWP.

If the pull request from @dotMorten takes a while to merge in, maybe someone could take that implementation and move it to a separate "pre-release" NuGet package managed by the community until/if we get official support. That way we can use it without using a full pre-release or custom build of Xamarin.Forms. If we don't get official support, then the repo will already be setup and the community can take over.

[dotMorten]

I'm sorry this haven't moved faster. I hit some regressions when syncing up with master, and I've been completely swamped with work and family-related stuff, so just haven't had much time to really sit down and try and address it. However I'm more than happy to take PRs for my branch.

[luigicasalegno]

We also will use the shell as soon as it is available on UWP. We have the same problem as above. We have a mix of tablets, phones and notebooks both with android and windows. And we also think that the best development environment is UWP

[weitzhandler]

This issue is one of the main reasons I gave up on XF. To our customers, desktop and mobile have the same priority.

[papiermache]

What can I say that hasn't already been said ..

so GET ON WITH IT !
UWP support is not optional for Microsoft - do you really need to be told this?

[JeroMiya]

@papiermache please note the code of conduct applies to all communications, issues, and comments on this project

[dgerding]

Also treating this as a test of MS Xamarin commitment to devs. Anybody on MS side ready to weigh in?

[papiermache]

Sorry all, will temper further thoughts … but I was just totally blown away to discover the lack of UWP support – it never even occurred to me that UWP would not be an included platform from the get-go. Rick.

From: Jeremy [e-mail]
Sent: August 16, 2019 2:28 PM
To: xamarin/Xamarin.Forms [e-mail]
Cc: Rick Piovesan [e-mail]; Mention [e-mail]
Subject: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

@papiermachehttps://github.com/papiermache please note the code of conduct applies to all communications, issues, and comments on this project

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A.

[dgerding]

Hi @dotMorten, can you give any update? Are you still planning to try and get UPW+Shell working? Understand that is an act of kindness and community :) Just wondering since your efforts seem to be closest to getting Shell+UWP working. Still completely mystified by what seems like a Microsoft pivot away from Windows support with Xamarin. Grateful for all the other goodness, but still perplexed and frustrated.

[dotMorten]

Sorry. Sort of burned out right now, so I haven't revisited this. I remember merging with latest caused lots of regressions and just haven't had the time nor energy to bring it back up to speed. Also identified several things that would need to change and require broader buy in from the XF team but didn't get much support beyond "sure let's look into it" and then died out. Generally the support and feedback I got from the XF team was only encouragement but with a bit lack of follow through. Still waiting for feedback on the work I did but at this point it's probably too out of date. Hopefully I'll have some time and energy soon to get back into it.

[scottkuhl]

This issue currently is in the top 10 most commented open items but it is not on the roadmap to complete.

@pauldipietro can we get an update on this? It seems to me to be sending a signal that UWP support is no longer a priority for the XF team. If that is true, please tell us so we can make plans around that.

Thanks

[dgerding]

Agreed, I just want to know if XF isn't going to include Windows support. If not, I also want to know why not? Do they know what the "next" Windows UX stack is going to be other than UWP and don't want to waste cycles? Will some Blazor/HTML thing be the next piece? If so just let me(us) know so I can transition... Maybe to uno platform?

---

From: Scott Kuhl [e-mail]
Sent: Thursday, August 22, 2019 1:21:22 PM
To: xamarin/Xamarin.Forms [e-mail]
Cc: David Gerding [e-mail]; Comment [e-mail]
Subject: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

This issue currently is in the top 10 most commented open items but it is not on the roadmap to complete.

@pauldipietrohttps://github.com/pauldipietro can we get an update on this? It seems to me to be sending a signal that UWP support is no longer a priority for the XF team. If that is true, please tell us so we can make plans around that.

Thanks

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A.

[pedrolamas]

Quite frankly, seems to me that the best bet would actually be replacing XF with Uno Platform...

Xamarin has made clear that their target is mostly mobile devices (phones, tablets, watches), not desktop or laptops.

They have no interest in supporting and maintaining UWP themselves, so that is no good for me to recommend to my customers.

[dgerding]

I want to clarify my need: I don't need _UWP_ for Xamarin Forms. I need _some Windows target_ for Xamarin Forms. UWP just seems like the most viable candidate. If I had to guess Microsoft will eventually punt and go to HTML and Blazor client for desktops since it might give them the broadest UX reach in a post-Windows world. That might also fit better with a composable shell (not xf shell) path. In the absence of any coherent roadmap for the Windows side of UX, I can't imagine what else they might be planning.

But to be clear, dropping Windows support for Xamarin without announcing in big bold letters, "WE DON'T AND WON'T DO WINDOWS", is, at a bare minimum, really, really unkind. It rings of "old Microsoft".

@davidortinau et al: Please do something more than pointing to the now effectively dead (see @dotMorten's latest post) "community support for XF Shell + Windows".

I am super grateful for all the new and cool things in Xamarin. But I need a more honest response about the future viability, if any, of Windows targets using Xamarin.

[PureWeen]

several things that would need to change and require broader buy in from the XF team

I know one of these had to do with WinUI which we are hoping to pull in as a dependency with this PR
https://github.com/xamarin/Xamarin.Forms/pull/7214

That PR maintains 16299 compatibility and from my tests works great when it's included with a nuget and doesn't require the user to install WinUI. I still need to get 16299 spun up in a VM to make sure but I'm staying optimistic. I know @dotMorten you had expressed some concerns around pulling in WinUI so if I've totally ignored those please let me know :-)

Here's that nuget.

Xamarin.Forms.4.3.0.1853.zip

If anyone else would like to test it out for us and let us know if you have any issues that would be really helpful. I've tested it with the basic UWP template and it works fine for me with no crashes.

The path I see for this currently is

• get #7214 merged so that we've taken care of the WinUI depedency
• get the UWP Shell PR rebased (we have this scheduled for a future sprint so we'll either do it then or if someone else beats us to it)
• Morten already has it working with Gastropods so we just want to test it with a few more samples (mainly Xaminals), once that's working and we make any code cleanup changes that are needed we will merge

If I'm missing anything with that path let me know and we'll try to get it addressed, so all that needs to be done is a rebase and a verification against Xaminals.

[dgerding]

@PureWeen,
I can run the App132.zip with the Xamarin Nuget you provided. App seems to work fine ... assuming it's supposed to add timestamped elements to list control. Both the button at the top and the Pull to Refresh behavior add elements.

Not sure what I'm looking for but I appreciate your efforts and will try and help as I can.

Dave G

[dotMorten]

@PureWeen Great to see you're moving forward with WinUI. The dependency on WinUI was creating breaking behaviors for me, as WinUI was adding a dependency that wasn't added transitively. That's fixable if you use VS2019, but I'm not sure if WinUI has taken advantage of that feature yet (and it'll still affect VS2017 users, but at least has a workaround).
In addition there were bugs in WinUI that caused a lot of headaches for me, but I've noticed recently some of the ones I logged got fixed, so that's all encouraging. Ping me once 7214 goes in, and I'll try and start this effort up.
Also would love help with rebasing. Last time I did that, I totally messed up this PR :-)

[PureWeen]

@dotMorten Sounds good!!

I did test the app I included above on VS 2017 and it worked for me so I think we're ok on that front

Not sure what I'm looking for but I appreciate your efforts and will try and help as I can.

The main thing would be adding the nuget into your main UWP project and just making sure they all seem to compile and run ok.

Just trying to vet that adding a WINUI dependency isn't going to cause any headaches :-)

[dotMorten]

I did test the app I included above on VS 2017

Without also adding WinUI to the project head? That is the issue I found: if people were to upgrade to a version of XF that depends on WinUI it wouldn't work without also manually adding a dependency to WinUI. IMHO that's a breaking change. WinUI can change their package so it works implicitly, but it would require VS2019 as it relies on a NuGet 5.0 feature (and afaik they haven't made this change so it won't work in either right now).

[dotMorten]

Here's the issue I logged in WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment-524187369

I might just make a quick PR to at least address that so VS2019 users wouldn't have to manually add the extra dependency.

[dgerding]

Just adding that when I tested the app123 it was with VS2019.

[PureWeen]

Without also adding WinUI to the project head?

Yea the project I have linked above I can open inside VS2017 and it compiles and runs fine. I don't have the WinUI nuget added to the UWP head it's only indicated as a dependency inside the nuspec

[dotMorten]

I don't really get how that works. There's a style that needs to be added and an extra appx framework package that needs to be installed with the package, and it's all done by the .targets. Are the framework package already installed on your machine?

[scottkuhl]

Visual Studio Magazine just covered this issue in particular. Microsoft, time for an official response.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

[PureWeen]

@dotMorten I'm out for a couple days but I'll look into that when I get back. I've also reached out to the WinUI team to review

[PureWeen]

This target runs fine transitively when I tested on VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Here's an updated nuget that lets you override the setting in your local forms project
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

In the forms project we forced this to true so it won't surprise people.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff-5e6292d5925c776aa9aa6d6f8c63ddf6R19

[dotMorten]

@PureWeen This is the bit that should work without adding these lines explicitly (since all users would have to update their project heads too):

I think you're saying it does work, but just making sure we're on the same page.

It might be you consider this an acceptable breaking change, but I recall this happened recently with another dependency and threw a lot of people off, as the upgrade path isn't as clean as just picking a new XF version.

[SteveReillyBayridge]

Re: the need for a desktop/laptop/tablet target for Xamarin Forms

For those of us who are building mobile apps in corporate environments, the ability to produce a "work-alike" desktop/laptop executable from the same basic code base as the Android/iOS base is essential. It doesn't need to be Windows only (a browser-based target such as HTML/JS would be just as good) but the vast majority of our users have a Windows desktop/laptop + iPhone/Android phone, so a Windows executable is fine for the most part.

We have found that when we make a mobile app available within the organization, the majority of our users want to try it out on their laptops/desktops first - and only if they find it useful or appropriately matched to their needs will they deign to put it on their phones. Also, getting user buy-in (and feedback) works significantly better if they can enter data or query results from either desktop or device, depending on where they are working at that particular moment.

Xamarin Forms works well for these scenarios, and we'd really like to use Shell and CollectionView, but they are shelfware to us until they can be used to produce a desktop/laptop work-alike...

[PureWeen]

@dotMorten so the reason I'm not seeing the exception is that I have WinUI as a dependency on the nuget so if you install XF onto the UWP head then WinUI comes along for the ride and applies its targets.

This does make it so the XF package itself has to be installed onto the UWP head project in order to work. I tested my example above with having XF only installed on the netstandard project and was able to recreate your exception.

We've talked about this a bit over in this issue
https://github.com/xamarin/Xamarin.Forms/issues/4126

This is breaking if people only have XF installed into the shared library and not the UWP head project. So we'll need to discuss this a bit to see what we want to do about this

[dotMorten]

@pureween ok good. Glad we're seeing the same thing then. A few things to consider in your discussions:

• If my PR in WinUI gets merged it'll only affect VS2017 users (which however could get weird if a team uses both and it only affects some users).
• You could detect this during Init() and throw an error that tells users exactly what to do so the pain isn't so bad.
• I was toying with the idea that XF has a targets file that adds the dependency to the referring project if not already present, but could
  create a weird dev experience.
• All UWP projects will always use this dependency once WinUI gets separated from the platform (but by then VS2017 is probably out of support anyway).
  
  
  
  • You'll be able to support lower versions of Win10 with this change, creating a value add that could justify it.
  
  
  • No one will notice because according to your team, no one really uses UWP anyway 😜 j/k
  
  

[dotMorten]

One more possible approach: Detect if WinUI is referenced during Init, but let the app run. Any renderer that relies on WinUI would instead throw, so it'll only affect users of these new features. So the story becomes "If you want to use Shell or PullToRefresh you must also add a reference to WinUI (if you are on VS2017)".

[mnasers]

@dotMorten Thank you for all your efforts regarding bringing Shell to UWP! This is very much needed and should have been addressed by the core Xamarin team.

[PureWeen]

Here's a taste of Xaminals running on UWP with CV and Shell!!!

[velocitysystems]

Great work!

[luigicasalegno]

Fantastic job. We will include it in our framework for building enterprise level applications as soon as it comes out

[Nioux]

Great job, I will try it in a future release of my app ;)

[abrantie1z]

Yes, Xamarin Did it! i read one guy say we move to Uno. No!!!! Xamarin has been great for us and saved us lots of time to having to go learn swift + java. Lets be patient with the team and support them

[samhouts]

closed by #6015

[XamarinTounsi]

Great Work, thanks for all team <3, i will turn it 💃

[DiagProf]

Great Work, thanks a lot!

[curtisconner]

OK something strange is happening, I upgraded my project to use the 4.3.0.947036, now the project fails when calling forms.init with
'Could not find Windows Runtime type 'Microsoft.UI.Xaml.Controls.XamlControlsResources

What is very strange is the amount of code now found in the XamlTypeInfo.g.cs, in the previous version of Xamarin we had only 13 entries, now we have over 43. I installed Win.UI Nuget on the project and still this does not help. Any ideas

[MappingSteve]

@abrantie1z - (although off-topic, I thought I'd mention) Uno and Xamarin Forms don't have to be a mutually exclusive choice any more - see https://platform.uno/xamarin-forms/ and https://visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Caveat: I haven't used Uno, so I have no idea how robust this support is. But anything that gets more people interested in XF in browsers is a Good Thing.