Uwp Xamarin.Forms.Shell

[allessandrojs]

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]

#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

[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
#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)".

[mnazers734]

@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.