Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Update to .net core 3.1. #3571

Open
wants to merge 9 commits into
base: master
from
Open

WIP: Update to .net core 3.1. #3571

wants to merge 9 commits into from

Conversation

@grokys
Copy link
Member

grokys commented Feb 14, 2020

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.
Also remove netfx targets as they seem to interfere somehow with net31 targets, and pin SDK in global.json.
@grokys grokys requested review from kekekeks and AvaloniaUI/core Feb 14, 2020
@MarchingCube

This comment has been minimized.

Copy link
Member

MarchingCube commented Feb 14, 2020

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

@MarchingCube

This comment has been minimized.

Copy link
Member

MarchingCube commented Feb 14, 2020

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

@grokys

This comment has been minimized.

Copy link
Member Author

grokys commented Feb 14, 2020

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?

@@ -1,7 +1,7 @@
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>
<TargetFrameworks>net461;netcoreapp3.1</TargetFrameworks>

This comment has been minimized.

Copy link
@grokys

grokys Feb 14, 2020

Author Member

Not 100% sure we want to change this?

This comment has been minimized.

Copy link
@kekekeks

kekekeks Feb 14, 2020

Member

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

@grokys

This comment has been minimized.

Copy link
Member Author

grokys commented Feb 14, 2020

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 added 3 commits Feb 14, 2020
3.1 doesn't work for some reason.
@grokys

This comment has been minimized.

Copy link
Member Author

grokys commented Feb 14, 2020

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.

@grokys grokys changed the title Update to .net core 3.1. WIP: Update to .net core 3.1. Feb 14, 2020
@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 14, 2020

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

@grokys

This comment has been minimized.

Copy link
Member Author

grokys commented Feb 14, 2020

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

@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 14, 2020

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

@MarchingCube

This comment has been minimized.

Copy link
Member

MarchingCube commented Feb 15, 2020

@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

This comment has been minimized.

Copy link
Contributor

Gillibald commented Feb 15, 2020

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

@MarchingCube

This comment has been minimized.

Copy link
Member

MarchingCube commented Feb 15, 2020

@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

This comment has been minimized.

Copy link
Member

jmacato commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

@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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

@jkoritzinsky

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Contributor

ahopper commented Feb 15, 2020

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

This comment has been minimized.

Copy link
Member Author

grokys commented Feb 15, 2020

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

@jkoritzinsky

This comment has been minimized.

Copy link
Member

jkoritzinsky commented Feb 15, 2020

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

@kekekeks

This comment has been minimized.

Copy link
Member

kekekeks commented Feb 16, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.