Drop .NET Framework in favor of .NET Core?

[eXpl0it3r]

SFML.NET has been slightly abandoned in the last few months and I'd like to change that with everyone's help.

One of the first things we need to do, is decide what direction SFML.NET should take.

• Do we want to keep supporting .NET Framework?
• What are the advantages of keeping support for the .NET Framework?
• Are we going to support .NET Core only?
• Are we supporting .NET Core 2 or also any other version?
• What are the advantages of .NET Core 2?

I think, we did answer some questions already, but let's try to collect all the arguments here and then have one place to "document" the decision here.

[eXpl0it3r]

Because creating a forum account takes less time than me having to requote, I'll provide the quote here.

I'll try to answer some of this questions here since I don't have forum account.

IMHO:

Do we want to keep supporting .NET Framework?

No. We have .NET Core as successor for .NET Framework with native support on all major plaftorms (Win/Linux/OSX)

What are the advantages of keeping support for the .NET Framework?

None.

Are we going to support .NET Core only?

Yes,

Are we supporting .NET Core 2 or also any other version?

We should keep supporting .NET Core 2.0+ versions

What are the advantages of .NET Core 2?

Speed, "native" multi-platform support (vs Mono), support for future versions, etc.

I think there is some misunderstanding here about different .NET versions.
All libraries here are .NET Standard v2.0 version not .NET Core libraries.

.NET Core standard libraries can be used BOTH in .NET Core and .NET Standard. Here are list of supported framework versions.
Just to note, opposite doesn't stand, .NET Framework assemblies are not fully supported in .NET Core.

So, to summaries why we need this PR. We use it to build .NET Standard libraries and reference them in both .NET Core & .NET Framework applications (as nuget package). Currently we can not use them in .NET Core application.

Just for reminder, changes in this PR are almost zero in code (some labda refactoring etc.) and a lot of changes in project files (they are not same for .NET framework vs .NET Standard/Core) and how project is published (nuget).

Here are some helpful links about different libraries:

• What is the difference between .NET Core and .NET Standard Class Library project types?
  
• MSDN - .NET Standard - Demystifying .NET Core and .NET Standard
  
• and this .NET Core vs .NET Framework: How to Pick a .NET Runtime for an Application.
  

I hope this will clarify why we are trying to ditch old .NET Framework.

@Balnian, @dabbertorres, @eXpl0it3r

You are always welcomed to try my fork for testing before approving this PR (I really hope that you will, so that we can polish any problems before merge).

Cheers

[eXpl0it3r]

I 100% agree with what @dsoronda said, this was also discussed in #141 but we never decided on an official stance. I sincerely think we should, from now on, only offer .Net Standard 2.0 libraries that will require .Net Framework 4.7+ to work or .Net Core 2.0

Also about the nuget distribution, I think we will be able to ship csfml precompiled libraries for each platform, inside the nuget package.

[Balnian]

I think we should support .Net Standard 2.0 only, this will allow for .Net Core 2.0 and .Net Framework 4.6.2-4.7 support. As for the advantages of .Net Core 2.0 see those incredible blog post from Microsoft about the performance upgrade of .Net Core :
https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/
https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/

Finally, I think that sticking with .Net Standard 2.0 should last us for a while, because up to now, Microsoft kept all of their .Net Standards retro compatible. And in the event that isn't the case we will act according to the information that will be available at that time.

[Dude234]

It would be great if SFML.NET would advance to SFML.CORE at some point.
Why? Cross-platform, open source, and as claimed: more performance and modern design.

I was searching for libraries which are media / game frameworks and already use Core.
But it seems to be too early for such hopes? If SFML jumps early on this train, that would be great.

So the one thing I can bring into this disscussion is, if you want to keep sfml c# alive and more active, changing to core may be a good oppurtunity? Because people will look for something like this: libraries which are going to use CORE.

Since I live with a highly  outdated version of SFML.NET anway for quite some time now, I do not care so much about a updated one anymore, stuff mostly works. But I would be very hyped for SFML.CORE. That are my two cents.

[ross]

hey eXpl0it3r

I've been using SFML.NET to develop a game for the last few months and will be continuing through to late next year so despite being a little late to this discussion i'll provide my two cents.

As someone who is still using .NET Framework I will confirm SFML should be moved to .NET Standard as this assures its compatibility with the various CLR platforms (.NET Core and .NET Framework). For as long as SFML.NET only relies on whats available under .NET Standard there shouldn't be any compatibility concerns and means you don't necessarily need to keep a .NET Framework branch for legacy reasons.

A note to why i'm still using .NET Framework (other than its what SFML currently provides) as it may clear up some concern for this migration.

.NET Core the main CLR platform at discussion here was initially made for console application development in the cloud which really doesn't fit with where SFML gets used. As a result certain namespaces for UI and basic graphics/imaging in .NET Framework aren't available in .NET Core without 3rd party support.
I so happen to be using these namespaces (e.g WinForms and Drawing namespaces) and cross platform isn't a big priority for me at this time.

I want to point out the upcoming .NET Core 3 looks to potentially add what i'm using anyway to help those such as myself move from .NET Framework to .NET Core as that is the preferred platform choice for the future.

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/


I can't think of any other real reason at this current time why you might stick with .NET Framework and so its reasonable to see SFML.NET move forward as a .NET Standard library.