Mvvmcross: Support for netstandard1.4 in version 6.0
I propose to support Netstandar1.4 in version 6.0. The is being used any feature of Netstandar2.0, and is lost compatibility with previous versions to UAP 10.0.16299. Windows Mobile compatibility is lost.
Steps to reproduce :scroll:
- Replace Netstandar2.0 to Netstandar1.4 reference in project files.
Expected behavior :thinking:
Tell us what should happen
Actual behavior :bug:
Tell us what happens instead
Configuration :wrench:
Version: 6.0
Platform:
- [ ] :iphone: iOS
- [ ] :robot: Android
- [ ] :checkered_flag: WPF
- [x] :earth_americas: UWP
- [ ] :apple: MacOS
- [ ] :tv: tvOS
- [x] :monkey: Xamarin.Forms
andres-gimenez
All 7 comments
@andrechi1 unfortunately this isn't going to be possible without a lot of work. I understand that it would be nice so that earlier version of UWP can be supported but the reality is that the cost of maintaining the project with netstandard 1x support is just too high. I'm sure the team would consider a PR from someone willing to do the work but it's not something that is in the priority list atm from my understanding
nickrandolph
on 2 Mar 2018
@nickrandolph Nothing is being used in MvvmCross that needs Netstandard2.0, either UAP 16299. Most bookstores in NuGet require earlier versions of Netstandard. If the problem is the cost, can be left alone Netstandard1.4
andres-gimenez
on 2 Mar 2018
@andrechi1 I do understand that there are parts of MvvmCross that could be targetted to 1.4. However, there are things that v6 is now using that are netstandard2.0. Maintaining 1x will require a lot of complex duplication now that it uses multi-targetted projects - the overhead of managing this is just too high to warrant the effort required to do it. I was initially of the belief that adding 1x support would be trivial but then I went down the path of trying it (see the abandoned PR https://github.com/MvvmCross/MvvmCross/pull/2555) but it was going to be too messy and the investment of effort was better spent improving v6
nickrandolph
on 2 Mar 2018
@nickrandolph I have searched the incompatibilities with Netstandard 1.4 and there are only two classes. In MvxSetup, AppDomain is being used and in EntLibLogProvider reflection is utilized. It's a shame not to be able to migrate to V 6.0 for these two things, to maintain compatibility with Windows Mobile.
I think the decision to get to Netstandard 2.0 has been taken very lightly. Although Microsoft has also taken it with EntityFrameworkCore.
andres-gimenez
on 2 Mar 2018
@andrechi1 nothing about the decision was made lightly, and in fact the migration to netstandard 2.0 and multi-targetting took a lot of dedication and effort by the core team, and is still not complete. As I pointed out, if someone was prepared to do the PR necessary to add 1x support, I'm sure it would be considered as it would add value to mvvmcross. However, as you'll note from the committ history, the bulk of the work on mvvmcross is done by a few core members.
What you don't see when you look at the compatibility is the message of nuget packages that are required for 1x. There are classes that there are no 1x support for, which means we need different logic for 1x than we do for 2x (and yes, this is an issue with Microsoft nuget packages that do not support 1x).
In so far as Microsoft choosing to support 1x for their libraries, they have a commercial interest in doing so (especially considering only the FCU supports netstandard2.0). No one is getting paid to maintain mvvmcross, so we need to prioritise where the contributions are made.
The decision not to support 1x was made (as per the abandoned PR) but it isn't final. If you, or anyone in the community, wants to contribute the PR, I'd be happy to review it.
I hope this explains a bit of background on this decision - I do understand the position it puts you in. If you're not ready to migrate to netstandard 2.0, v5.6.3 was stable and is the preferred option for the time being.
nickrandolph
on 3 Mar 2018
@nickrandolph Can you give a brief overview of what's missing from netstandard 1.4 that prevents targeting it? Would give prospective contributors an idea of whet they'd get into if attempting to add support.
claudiuslollarius
on 7 Mar 2018
@claudiuslollarius please take a look at the now abandoned PR (https://github.com/MvvmCross/MvvmCross/pull/2555) - you'll see quite quickly where the issues are
nickrandolph
on 7 Mar 2018
Related issues
ehuna
路
3Comments
ueman
路
4Comments
merckxite
路
4Comments
prin53
路
4Comments
a7ex
路
3Comments
Most helpful comment
@andrechi1 nothing about the decision was made lightly, and in fact the migration to netstandard 2.0 and multi-targetting took a lot of dedication and effort by the core team, and is still not complete. As I pointed out, if someone was prepared to do the PR necessary to add 1x support, I'm sure it would be considered as it would add value to mvvmcross. However, as you'll note from the committ history, the bulk of the work on mvvmcross is done by a few core members.
What you don't see when you look at the compatibility is the message of nuget packages that are required for 1x. There are classes that there are no 1x support for, which means we need different logic for 1x than we do for 2x (and yes, this is an issue with Microsoft nuget packages that do not support 1x).
In so far as Microsoft choosing to support 1x for their libraries, they have a commercial interest in doing so (especially considering only the FCU supports netstandard2.0). No one is getting paid to maintain mvvmcross, so we need to prioritise where the contributions are made.
The decision not to support 1x was made (as per the abandoned PR) but it isn't final. If you, or anyone in the community, wants to contribute the PR, I'd be happy to review it.
I hope this explains a bit of background on this decision - I do understand the position it puts you in. If you're not ready to migrate to netstandard 2.0, v5.6.3 was stable and is the preferred option for the time being.