.Net Core Real Talk

[Balnian]

Hi, there's now 2 PR for a .Net Core conversion to SFML.Net, but one thing people don't seem to understand, is that changing the project to .Net Core has impact on the minimum version of of .Net Framework that will be needed to use SFML.Net (the minimum version will become 4.5+) https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-platforms-support

Also some things are not yet in for .Net Core like VB support coming in 2.0 https://blogs.msdn.microsoft.com/dotnet/2017/05/10/announcing-net-core-2-0-preview-1/, missing CriticalFinalizerObject (also coming in 2.0) and OpenTK has not been updated to .Net Core yet.


But, on the other side, we would be able to build SFML.Net project that would work on Linux, Mac, Windows, ... all natively, there's also the fact that .Net Core is faster then .Net Framework https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/

Finally... should we change SFML.Net to.Net Core or create a new binding called SFML.Net Core (or something else...because this one might confuse some people)

Please use this post to discuss the matter, it's not an official/sanctioned post but i think it's an healthy discussion to have together.

[dabbertorres]

Appreciate it Balnian!

For reference and some catch up for those interested: https://github.com/SFML/SFML.Net/pull/141 has the most discussion.

My opinions:

Waiting for .NET Core 2.0 to be released should be considered; that way currently supported features aren't removed (ie: Visual Basic support).

Native support for Linux and OSX is a big bonus.

I'm not certain about upping the minimum .NET framework version. Need feedback from others.

OpenTK not being updated yet gives me pause.

[Balnian]

I spoke with OpenTK people and they are waiting for .Net Core 2.0 too

Expect support fairly soon after netstandard 2.0 is release

Also there's a preferred way to "map" dynamic library name for dllImport https://github.com/dotnet/coreclr/issues/12103

[dabbertorres]

I read this and the issue you linked a while ago, and forgot to reply!

Awesome, thanks for reaching out to OpenTK, sounds like SFML.NET should target that too then.

For dllimport, that was the solution I had in mind when we first started discussing that, so that makes sense to me.

[Kazumi]

I honestly fail to understand why you are wanting to switch to .NET Core in the first place. A modern .NET library (as this one aims to be) targets .NET Standard, a common ground between ALL .NET platforms, be it .NET Framework, .NET Core, Mono, or UWP.

Please, have a look at Microsoft's documentation on .NET Standard, and then rethink if you should target .NET Core, continue targetting .NET Framework, or target .NET Standard.

[dabbertorres]

Yes, .NET Standard is the ideal target. I'd consider this change to .NET Core a stepping stone towards that, since, as far as I am aware, .NET Core is the "closest" to the bare standard.

Some work to ensure SFML can function correctly while using no more than .NET Standard (and make the necessary changes, if any) will need to be done (as was done for .NET Core).

[Balnian]

I agree that .Net Standard is the ideal target for a Library only, but we also have to maintain the exemples which cannot be .Net Standard (since it's only a rule book and not an implementation) .
So yes we should most definetly target .Net Standard 2.0 for the core binding but the exemples should be targeting .Net Core 2.0