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

Bring back uap10.0/netstandard1.4 support #3533

Closed
steffenloesch opened this issue Aug 10, 2018 · 8 comments
Closed

Bring back uap10.0/netstandard1.4 support #3533

steffenloesch opened this issue Aug 10, 2018 · 8 comments
Labels
in-progress This issue has an associated pull request that may resolve it! p/UWP partner/cat 😻 t/enhancement ➕

Comments

@steffenloesch
Copy link

As described in #2859 (comment) 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.

@fnktastic
Copy link

Does this issue is going to be solved?

@samhouts
Copy link
Member

We need to reconcile this with #5981.

@andreinitescu
Copy link
Contributor

andreinitescu commented Jul 23, 2019

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.

@samhouts
Copy link
Member

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

@andreinitescu
Copy link
Contributor

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

@samhouts
Copy link
Member

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

@dotMorten
Copy link
Contributor

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

@PureWeen
Copy link
Contributor

PureWeen commented Sep 5, 2019

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

@samhouts samhouts added the in-progress This issue has an associated pull request that may resolve it! label Oct 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
in-progress This issue has an associated pull request that may resolve it! p/UWP partner/cat 😻 t/enhancement ➕
Projects
None yet
Development

No branches or pull requests

7 participants