Mvvmcross: .NET Standard support

[martijn00]

It's time to move to .NET Standard! There are a couple of things we have to decide, and some optional refactoring we can do.

1. Are we going directly to .NET Standard 2.0 or do we pick a lower version for now?
2. Will we provide backwards support for PCL projects?
3. Do we use multi-target to only have 1 csproj per project which then contains all the code even for Android, iOS, etc? This could speed up the time to load the solution.

Tasks:

• [x] Move all projects over to the new .csproj format
• [x] Use the new Nuget packager

[Cheesebaron]

I dunno how UWP land lies right now. Looking at the NET Standard versions, it seems like 1.4 is the highest we can go if we want to support UWP today?

Since we are already using PCL's we won't have any issues with API not available. So a minimal viable implementation of this would be to convert all the PCL's to NET Standard (no project.json stuff, new csproj type) and adjust the NuSpecs and that should be that. That requires a good amount of grunt work or maybe someone think up some steps to automate this. Afaik the convert to NET Standard in VS currently converts to the old project.json stuff.

If the conversion goes well. I guess we then could look into multi-targeting. This again would require a bit more grunt work. I'd love a nice clean structure so it is clear what code gets built for what platform.

For using the new NuGet bits for NET Standard projects, can we still add content, like bootstrap files or how is that handled?

[martijn00]

Looking at how many projects we have in the solution, it might be good to refactor this right away into MultiTarget projects, explained here: https://oren.codes/2017/01/04/multi-targeting-the-world-a-single-project-to-rule-them-all/ and https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20

Doing this would make it easier to develop, but also speed up loading of the solution a lot.

Another proposal for MvvmCross 6.x i would like to make is doing the same as https://github.com/Reactive-Extensions/Rx.NET/issues/199
We have a lot of projects, and some are almost always required. The proposed new structure could be:

Assembly/csproj: MvvmCross
Includes:

• MvvmCross.Core
• MvvmCross.Localization
• MvvmCross.Droid
• MvvmCross.iOS
• MvvmCross.Mac (Rename to MacOS)
• MvvmCross.tvOS
• MvvmCross.Uwp
• MvvmCross.Wpf
• MvvmCross.Console

Assembly/csproj: MvvmCross.Binding

• MvvmCross.Binding
  This also includes all subprojects for Binding targets like, Android, iOS, Uwp, etc. Using MultiTarget we should be able to do this.

Assembly/csproj: MvvmCross.Platform
Includes:

• MvvmCross.Platform
• MvvmCross.Platform.*

The plugins could work as one csproj per plugin. The other remaining projects would stay as they are.

If we let the actual code files stay in the same namespace this should mostly be compatible for everyone. If we want this to be any even bigger change we could move namespace too.

[softlion]

I do not use MvvmCross.Localization. I have a better system based on a tt file which creates appropriate native translation files for each platform at compile time from resx files. This eliminates the need for resx satellite assemblies which slows down the whole app for many reasons.

Note that Microsoft have created lots of nugets for the .NET framework in netstandard. So don't do the reverse.

[softlion]

Using the new csproj format means using exclusively VS2017. Which uses an older version of Xamarin than VS2015. Not a real problem as the resulting nuget can still be used by a 2015 project.

[softlion]

Maybe this work can be split. One would be to update the nugets so they can be used by netstandard projects. The second would be to reorganize these nugets.

[softlion]

I would also stop shipping updated versions of plugins each time the core nugets are shipped. In fact i would ship only the real updated nugets. Which means having different versions for each.

[softlion]

MultiTarget projects seems more a hack that a stable and supported way do build projects. See the Gotcha’s chapter in your link. I would stay away from it, even if the promise is good. And also for another reason: it makes working on different part of the same library by different people more difficult. I prefer people to work on different projects. But that's a small gotcha compared to the ones listed.

[Cheesebaron]

@softlion instead of making 5 posts, please just edit your first one instead...

I do not use MvvmCross.Localization. I have a better system based on a tt file...

So? The linker will just strip out the code for it if you don't use it. Your comment here does not contribute anything to the NET Standard discussion.

Note that Microsoft have created lots of nugets for the .NET framework in netstandard. So don't do the reverse.

What do you mean? That you prefer having a lot of nugets for MvvmCross still than just adding a few? What about managing dependencies? How about quality of life when developing MvvmCross?

Using the new csproj format means using exclusively VS2017

Doesn't matter, we are building with VS2017 anyways. VS2017 community edition is free for anyone to use, so there is no real reason to not have it when working on MvvmCross.

would also stop shipping updated versions of plugins each time the core nugets are shipped

This wont work if the API has changed in the core projects. This would also mean to have two different builds one for core, one for plugins, that also needs to detect which plugins where updated etc. Too much management compared to what you actually gain. We won't do this.

MultiTarget (..) it makes working on different part of the same library by different people more difficult

Why? We are still making our own branches and having reviews before pulling into develop. No one is working on the same exact code, this happens rarely.

[softlion]

The linker will just strip out the code

Not if you have Preserve tags in it. And there are.

That you prefer having a lot of nugets for MvvmCross still than just adding a few

With VS2017, nugets are hierarchical. So adding one will add all dependants nugets without messing with the root nuget view. So this is not an issue anymore and is encouraged to modularise a framework.

VS2017

VS2017 is not currently stable for Xamarin apps, and its Xamarin module is currently behind the one in VS2015. We hope this will change in the future of course.

Build management

This could be achieved automatically using appveyor / bitbucket / azure mobile build tunnels.
The issue there is about plugins. If the core change but a plugin does not, no need to update its nuget.

MultiTarget

This is a trick. Blog posts write it can break automatic build. Maybe it will work, maybe not. Lets try.

[Cheesebaron]

The preserve tags are a separate issue. If they are there, then they can very easily be removed.

In this case combining some of the packages is logical. Since you are practically always adding Platform if you are adding Core, also the truth in most cases the other way around, so in this case it does not make sense to split them up.
Having separate droid/touch/uwp nugets would not make sense as they are and will still just be targets in the nuget package.

VS2017

Bullshit. I use VS2017 for Xamarin apps daily and have no problems using it. It is stable, even if it may be behind one version of Xamarin for a couple of weeks. AppVeyor is even slower to update and we build there.

Build management

It is not a problem to just build automatically on AppVeyor, it is a problem and major overhead setting it up, managing versions and the likes of that. If the core changes and the plugin uses the core, and the API has changed, the plugin _needs_ to be updated. Don't be silly.

Can we end this bike shedding or what?

[softlion]

Preserve

1) It has to be said.
2) I know very few people using Link All, as it requires both specific understandings of what's happening and additional time to test with a 100% app covering to fix the release builds on real phones.

VS2017

So bugs are bullshit for you. Nice Spirit. Not everyone is using the prerelease versions with the blocking bugs fixed.

Build management

Plugins should be completely separated from the core, as they were last year. And you know it: you have your own plugins and you don't ship new versions each time mvvmcross changes. Like lots of mvvmcross plugins made by third parties.
I'm not speaking about "core plugins", which should not be plugins. Like MvxMessenger.

It's always an awful time when you have 10 nugets to update with no release notes. You don't know if you will need the day to fix changes. I know companies freezing the mvvmcross version for 6 to 12 months during the whole app development. And some have hard time to upgrade. That issue should disappear.

[Cheesebaron]

Preserve tags are still a separate issue and have _nothing_ to do with migrating to NET Standard. There is nothing to discuss in this issue about these. Make a _separate_ issue please.

Complain about VS2017 elsewhere, it has nothing to do with this NET Standard discussion. NET Standard libs are perfectly consumable in VS2015 too. If we choose only to build MvvmCross using VS2017 it has no implications for others. Contributors obviously need VS2017 installed, but can be installed alongside VS2015 perfectly fine.

We are not going to separate the plugins into their own repository. End of story, you are welcome to fork and do this yourself.

All releases of 5.x have been documented in the CHANGELOG file in the repository. We try to keep every minor release non-breaking, any jump in the major semver may contain breaking changes.

Could you please be a bit more constructive instead of derailing the discussion? This issue is about NET Standard and Multi-target. Not about versions, VS2017 or splitting repositories.

[softlion]

Preserve tags are still a separate issue and have nothing to do with
migrating to NET Standard. There is nothing to discuss in this issue about
these. Make a separate issue please.

Complain about VS2017 elsewhere, it has nothing to do with this NET
Standard discussion. NET Standard libs are perfectly consumable in VS2015
too. If we choose only to build MvvmCross using VS2017 it has no
implications for others. Contributors obviously need VS2017 installed, but
can be installed alongside VS2015 perfectly fine.

There is a new type of project in vs2017, which does not use any
project.json file. These are not compatible with vs2015. And vs2015 is
quite bad at consuming netstandard libs, and has multiple small issues.
There are also some Microsoft nuggets which refuse to install in vs2015,
the error being "you must update to vs2017".
Obviously vs2015 wont't support net standard 2.
This only means enterprise mvvmcross users will need to wait for the next
stable xamarin version, which is beta, and will be available in the next 2
months, praying there is not another blocking bug in this release.

are not going to separate the plugins into their own repository. End of

story, you are welcome to fork and do this yourself.

This is bad practice to update plugin versions when there is no change in
them. Dependencies are managed automatically, and unless there is a plugin
interface change, there is no need to update them. As mvvmcross release
cycle is now short, a dev will have to update and retest too much unrelated
nugets in each app (I hope you are retesting your app each time you update
an external nuget).

All releases of 5.x have been documented in the CHANGELOG file in the

repository. We try to keep every minor release non-breaking, any jump in
the major semver may contain breaking changes.

Could you please be a bit more constructive instead of derailing the
discussion? This issue is about NET Standard and Multi-target. Not about
versions, VS2017 or splitting repositories.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MvvmCross/MvvmCross/issues/2059#issuecomment-318924103,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALpJCTjUXffkFXwkG15QY0Ac040h6Qwks5sTNsAgaJpZM4OeDCa
.

[mattleibow]

I have been using .NET Standard for a bit now and I may have some "tips" (or observations) when moving from a PCL or other type.

• By default, a .NET Standard library will append the framework name to the output path.
  For example, if you specify the output path to be "bin/debug" and target "netstandard1.1", the final location for the binaries will be: "bin/debug/netstandard1.1".
  The way to avoid this is to set <AppendTargetFrameworkToOutputPath> to false. (see https://github.com/dotnet/sdk/issues/844)
  This, of course, prevents you from specifying multiple targets (such as "netstandard1.1" and "net46" simultaneously).
• .NET Standard 1.1 my be sufficient.
  Since you are coming from PCL, it may be sufficient to use netstandard1.1 (see https://docs.microsoft.com/en-us/dotnet/standard/net-standard)
  As @Cheesebaron mentions, UWP has a max version of 1.4, so I don't think we can go higher just yet.
• By default, a .NET Standard library will generate an AssemblyInfo.cs file under the hood - and will cause compiler errors if not handled (either by disabling the generation, or by removing the existing). (see https://github.com/dotnet/sdk/issues/302)
  To prevent this generation, just set <GenerateAssemblyInfo> to false.
  The benefit of the generated file is that you can set the values in the .csproj (or via env vars)
• I also noticed that UWP had some issues with types not found (core .NET types) when using the latest version of the NETStandard.Library NuGet. (see https://github.com/dotnet/sdk/issues/1038)
  To avoid this, I build against v1.6.0, which is set by using the <NetStandardImplicitPackageVersion> and setting a value of 1.6.0.

[Cheesebaron]

The File plugin would no longer be relevant with NETStandard as all needed stuff is already in there. So we should probably look into removing it.

[mattleibow]

Just did a quick check, File and Directory are available in .NET Standard 1.3+. I am sure there is a way to just look at a table, but the code compiles :)

[tomkulaga]

https://blog.xamarin.com/share-code-net-standard-2-0/

Seems UWP has been added to 2.0 with the fall creators update

[Cheesebaron]

Yeah, there is support in the latest VS preview. We could maybe do the upgrade to 2.0 right away, although forcing people to use a VS preview when working on their UWP app for now.

[MartinZikmund]

But this would force also targeting FCU for their apps and cutting off Windows 10 Mobile altogether, no?

[Cheesebaron]

Not 100% sure what the preview covers. However, I certainly hope Fall Creators Update will hit mobile devices as well.

We need to try it out and see how it goes.

[HappyTreesDev]

I am curious if this has been done yet. I am interested in using mvvmcross but more interested in using .net standard

[Cheesebaron]

@HappyTreesDev you can still use MvvmCross even if we haven't migrated. You will just need to add a PackageTargetFallback in your csproj file in your .NET Standard project, in order to consume PCL's

[HappyTreesDev]

@Cheesebaron Oh right! I totally forgot about that ability. Thanks for reminding me!

[viktand]

Hi all,
So, can i now use netstandard 2.0 in my project on mvvmcross? And how?

[KennethKr]

https://www.mvvmcross.com/documentation/getting-started/netstandard

[viktand]

Thank, KennethKr

[softlion]

You don't need to follow the link.
You don't need to do anything.
If using VS2017.

Just create a netstandard 2 lib, and add mvvmcross nuget packages.
No need to mess with csproj.

[fonix232]

Quick question. Will there be any other incremental updates for the 5.x.x versions, or 5.6.3 is to be considered last, and the next update is directly to 6.0?

[Cheesebaron]

@fonix232 probably no more releases for 5.x.x, although we could consider doing a 5.7 which bumps dependency versions for Android Support libs.

[TheAifam5]

It's that normal ?

Package 'MvvmCross.Platform 5.6.3' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

Empty .NET Standard DLL project and only added MvvmCross package.

[nickrandolph]

This is a result of adding the 5.6.3 version to a netstandard 2.0 library. Make sure you add the nuget package to all head projects and you should be good to go