Update to .net core 3.1.

[grokys]

What does the pull request do?

• Update sample apps to netcoreapp3.1
• Remove netfx targets from samples as they seem to interfere somehow with net core targets
• Pin SDK in global.json.

[MarchingCube]

Maybe we can bump benchmarks as well? Since I was always doing that manually anyway.

[MarchingCube]

It also would be great to multi target .net standard 2.1 as well in the main projects.

[grokys]

Ah yeah, I also need to bump unit tests.

Not sure about dual-targeting .net standard 2.1, what does everyone think? Is it likely to cause us any problems?

[grokys]

Not 100% sure we want to change this?

[kekekeks]

Host app TFM should match the TFM of Avalonia.DesktopRuntime. Which is not changed by this PR.

[grokys]

Also /Packages/Avalonia/Avalonia.csproj multi-targets netstandard2.0;net461;netcoreapp2.0 - not sure why it does this, do we want to change that to 3.1 too?

[grokys]

Ok, seems nuke is failing on .NET core 3.1, looks like we're going to have to upgrade it, but there have been a lot of breaking changes between 0.12 and 0.24, so this looks like it's not going to be as straightforward as I'd hoped. Marking this PR WIP for now.

[kekekeks]

Could we use both .NET Core 3.1 and the oldest supported one instead? We are targeting netcoreapp2.0 TFM anyway.

[grokys]

Ah yeah, i meant to change Avalonia.DesktopRuntime to 3.1 as well. Is there any reason to target 2.0 still?

[kekekeks]

OSX 10.12 is not supported by .NET Core 3.1. Not sure if we care about that.

[MarchingCube]

@kekekeks It looks like only 7% people use macOS 10.12 at the moment and it is shrinking (according to https://gs.statcounter.com/macos-version-market-share/desktop/worldwide).

@grokys It would be good to figure out .Net Standard 2.1 support soon, since it is blocking certain work (like improving our string tokenizers and providing more span based optimizations).

[Gillibald]

What exactly will perform better with the tokenizer under. Net Standard 2.1?

[MarchingCube]

@Gillibald Almost everything :) Since it currently works on substrings https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Base/Utilities/StringTokenizer.cs#L43. And .Net Standard 2.1 adds ReadOnlySpan<T> based overloads for parsing, so we could do tokenization without allocations.

https://apisof.net/catalog/System.Double.TryParse(ReadOnlySpan%3CChar%3E,NumberStyles,IFormatProvider,Double)

[jmacato]

It'd be great if we could move all our targets to netstandard2.1 and netcoreapp3.1. so many perf stuff in it as @MarchingCube said.

[kekekeks]

netstandard2.1 is not supported by net4xx TFMs. Which makes it impossible to run our unit tests on Mono. That would be a road blocker for mobile platform support 👎

We can add netstandard2.1 if and only if we'll be multitargeting netstandard2.0 as well with polyfilling missing APIs.

[jkoritzinsky]

IIRC Mono does support netstandard2.1 but there’s just no good way with the standard tooling to do it.

[kekekeks]

@jkoritzinsky That's simply because there is no desktop Mono target framework moniker. It has to reuse net4xx while being a superset of that API.

[kekekeks]

Also, keep in mind, that while .NET 5 will have Mono as a runtime option, Xamarin platforms aren't migrating from the full mono codebase anytime soon.

[jkoritzinsky]

I don’t know if you saw the new TFM design spec for .NET 5, but Xamarin is planning on moving to a .NET 5 based TFM if all goes according to plan.

[kekekeks]

If I understand correctly, the BCL will still be based on mono/mcs/class rather than one from dotnet/runtime repo.

[jkoritzinsky]

Now that I’m not sure about. But considering a very significant portion of the BCL is shared, I wouldn’t worry about BCL differences being our problem. Our Mono-specific issues have almost always been runtime issues around either bugs or underdefined behavior.

[kekekeks]

Also, keep in mind that since we'd be shipping our NativeControlHost in the next release, embedding WPF/WinForms controls into Avalonia is now possible. With existing Avalonia into WPF/WinForms embedding, the drop of net4xx TFM support effectively removes a rather painless way of migrating existing applications, people will have to update their existing WPF code first instead of migrating to Avalonia directly.

[jkoritzinsky]

I think we should do the following:

Make Avalonia.dll a ref assembly for all of Avalonia that targets netstandard2.0 with its implementation assembly just type-forwarding. Make the rest of the assemblies implementation-only and multitargetting. That way we can have a unified API surface on all platforms, have “public” types we don’t expose to users, and use platform-specific APIs under the hood for performance.

[kekekeks]

Make the rest of the assemblies implementation-only and multitargetting.

That would conflict with how AppBuilder currently works. Right now it's only provided by netcoreappXX and net4XX TFMs. On mobile it's provided by backend-specific Avalonia.iOS and Avalonia.Android packages. It's not provided by netstandard2.0 dll.

[jkoritzinsky]

AppBuilder is in the Avalonia.Desktop package right? I was referring to the stuff in the Avalonia package only. Sorry about not clarifying that.

[kekekeks]

AppBuilder is in Avalonia package itself. The only thing that's provided by Avalonia.Desktop is UsePlatformDetect().

[kekekeks]

For now I'd suggest to write the list of things that we need from netstandard2.1 and see if those could be polyfilled. It's not like we need Span overloads for System.IO.Stream that can't be implemented outside of BCL.

[ahopper]

I did try using the span parse overloads on Geometry.Parse, this did reduce the number of allocations but actually had only a small speed increase, the underlying double parsing code is slow and dominates, probably because it has to allow for every possible formatting option. There are possibly bigger gains by using custom number span parsing (compatible with net standard 2.0) or better still do the parsing in xamlil at build time.

[grokys]

Could we just #if stuff depending on the target framework? Or would that be too much of a hassle?

[jkoritzinsky]

I’m fine with using #if per TFM. I want the ref assembly though to ensure that our public surface area is consistent.

[kekekeks]

the underlying double parsing code is slow and dominates, probably because it has to allow for every possible formatting option

I guess we should just use some specialized parser.

Could we just #if stuff depending on the target framework? Or would that be too much of a hassle?

As long as it's something like:

int Foo(int bar)
{
#if NETSTANDARD2.1
      return System.Something.Foo(bar);
#else
      //Polyfill implementation here
#endif

}

Having separate code paths would be a maintenance burden

[matkoch]

@grokys @kekekeks please let me know if you need any help with updating the build.

[grokys]

Thanks @matkoch! Am I right in thinking that nuke 0.12 doesn't support .net core 3.1?

[matkoch]

I honestly don’t know about the compatibility implications between netcoreapp2.0 and netcoreapp3.0 but I can at least say that we made the switch with version 0.23 of nuke. do you really want to stay at 0.12?

…

On Tue 18. Feb 2020 at 22:00, Steven Kirk ***@***.***> wrote: Thanks @matkoch <https://github.com/matkoch>! Am I right in thinking that nuke 0.12 doesn't support .net core 3.1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3571?email_source=notifications&email_token=ABGGB7R3NRQW7GXLEU5F73TRDRD7NA5CNFSM4KVIVA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEME3W3I#issuecomment-587840365>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGGB7QZGKK3W7LQAPEIP43RDRD7NANCNFSM4KVIVA2A> .

[kekekeks]

I'd suggest to leave the Nuke-based project as is and update it in a separate PR.

[grokys]

I've merged in #3596 (which updates the nuke build to 0.24) and CI now passes. Unmarking as WIP.

[MarchingCube]

LGTM. Unless anybody has objections - we should merge this in and then deal with consequences if any arise :)