Xamarin.forms: Bring back uap10.0/netstandard1.4 support

Created on 10 Aug 2018  ·  8Comments  ·  Source: xamarin/Xamarin.Forms

As described in https://github.com/xamarin/Xamarin.Forms/issues/2859#issuecomment-409756690 by @samhouts Xamarin.Forms switched to only supporting .NET Standard 2.0 support, effectively dropping the support of UAP 10.0 and only supporting UAP 10.0.15138. So you can use Xamarin.Forms to create universal apps that run on Windows Fall Creators Update, but not previous versions of Windows.

This issue is about bringing back support for UAP10.0 in Xamarin.Forms, because many teams have hard requirements to target Windows versions before the Fall Creators Update. In particular, the OS that runs on Microsoft Surface Hub devices runs a version of Windows based on 10.0.15063, so you cannot use Xamarin.Forms 3.0 to create Universal Apps that run on Surface Hub devices.

in-progress mobcat UWP enhancement ➕

Most helpful comment

it's going to be hard to go back up to 2.0
Reverting to .NET Standard 1.4!? I have strong reservations against doing so. .NET Standard 2.0 has double the APIs vs .NET 1.6

@andreinitescu @dotMorten

I might be missing something obvious here but I don't think this PR is causing us to go backwards with the API surface we support.

We already support NS1.0 for the purposes of PCL.

https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/Xamarin.Forms.Core.csproj#L3

This PR just packages the NS1.0 version of our libraries with UAP opposed to the NS2.0 version. This way if you want to run your UAP applications on 14393 you can.

At this point you can already write a NS1.0 => NS 2.0 libraries and they will all run with XF

All 8 comments

Does this issue is going to be solved?

We need to reconcile this with #5981.

Reverting to .NET Standard 1.4!? I have strong reservations against doing so. .NET Standard 2.0 has double the APIs vs .NET 1.6 (so much more than 1.4!). Also, from the the total PC market, what's the market share for Surface Hub? Maybe 0.01% ? Another thing is, Surface Hub is 4 years old and v2 is going to be announced soon. I wonder if it also means an OS update for it is imminent.

@andreinitescu We hear you loud and clear (which is why this has sat here for nearly a year). Our goal is to find a solution that would allow us to keep both 1.4 and 2.0 compatibility.

Sorry, I didn’t want to be “loud”, just wanted to share my thoughts, you and the team know much better and have more information from all the different angles..

@andreinitescu No worries, it was just a figure of speech. We love the feedback! Keep it coming! Thanks!! :)

Would it be allowed in the future to have more APIs available if you target netstd2.0, so for instance you might not get access to a specific control, because it relies on newer APIs, and thus excluded from the netstd1.4 target?

I'd hate for this move to be holding back Xamarin.Forms. Once 1.4 gets added, it's going to be hard to go back up to 2.0 (since it's always easier to add support, than remove support).

it's going to be hard to go back up to 2.0
Reverting to .NET Standard 1.4!? I have strong reservations against doing so. .NET Standard 2.0 has double the APIs vs .NET 1.6

@andreinitescu @dotMorten

I might be missing something obvious here but I don't think this PR is causing us to go backwards with the API surface we support.

We already support NS1.0 for the purposes of PCL.

https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/Xamarin.Forms.Core.csproj#L3

This PR just packages the NS1.0 version of our libraries with UAP opposed to the NS2.0 version. This way if you want to run your UAP applications on 14393 you can.

At this point you can already write a NS1.0 => NS 2.0 libraries and they will all run with XF

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Hudhud picture Hudhud  ·  3Comments

simontocknell picture simontocknell  ·  3Comments

suihanhbr picture suihanhbr  ·  3Comments

Stensan picture Stensan  ·  3Comments

joseluisct picture joseluisct  ·  3Comments