Switch from .NET Core 3.1 to .NET 5

[bmello4688]

As a developer and user, I would like to move all projects to .Net 5 so that their is less maintenance and bugs supporting multiple development frameworks.

Discussion Items:
Will need some minor changes for MSBuild, such as WPF projects.
All users of stride will have to use .Net 5 not core or framework
Removing any code related to choosing framework or core

[xen2]

Current plan & latest discussions on this:

• We should probably skip .NET Core 3.1 and release .NET 5 directly to avoid the extra framework to support (& associated user project ugprades)
• Current idea was to have both .NET Core and .NET Framework only for a single version (4.0 or 4.1), making it easier for users to upgrade (i.e. user can test back and forth the same project without upgrade and without any other engine feature/behavior change). Then the next version (4.1 or 4.2) would drop .NET Framework.
  However that's something we could rediscuss.

[manio143]

If possible, could we setup the upgrade such that if someone needs to stay on .NET Core they could still do so by just compiling Stride themselves for another target? In other words, can we isolate breaking changes and possibly use if directives before completely dropping .NET Core reliant code in the next release.

[Perksey]

I suppose one thing I didn't think about is that .NET Core 3.1 is an LTS, whereas 5 is not. I don't know what Stride's support policy is, but unless the .NET 6 version comes out a few months after .NET 5 comes out, users may be forced to use an unsupported TFM. Same goes if the .NET 6 version of Stride has breaking changes which may defer an upgrade.

[tebjan]

We are in favor of the two steps strategy with fw and 5 support. Otherwise our fork would be hard to manage and makes pull requests harder. A transition period for existing projects is quite important for us, since upgrading will take us a few months of work.

[Zeroto]

I suppose one thing I didn't think about is that .NET Core 3.1 is an LTS, whereas 5 is not. I don't know what Stride's support policy is, but unless the .NET 6 version comes out a few months after .NET 5 comes out, users may be forced to use an unsupported TFM. Same goes if the .NET 6 version of Stride has breaking changes which may defer an upgrade.

The scheduled release date for .NET 6 is november 2021. So a year after .NET 5. .NET 5 support will end 3 months after the .NET 6 release.

[xen2]

BTW, here is some work I started on .NET 5 a few days ago: https://github.com/xen2/stride/tree/net5
Sadly I will have to put this aside for a few days (until I finish relocation).

[ericwj]

Risking saying what you already know but:

• Please align with this as far as at all possible, and with how Visual Studio works when multi-targeting: Target Framework Names in .NET 5. I think at least some of the MSBuild Extra's SDK foo is no longer needed and the more Stride is just standard .NET the better imho.
• .NET 5 is more compatible with .NET 3.1 than with .NET Framework.
• It is most likely almost effortless to not change much and go to .NET 5 and keep supporting both .NET Framework and .NET 3.1.
  • Almost nothing that is already written will change.
  • Most improvements and new code can be #if'deffed if at all needed.
  • Build steps might need work, but some won't be needed with .NET 5 I expect and they can be conditionally included during build, too. Based on TFM.
• For most people, imho especially games, staying on an LTS is pointless, because there will be monthly updates anyway, which you have to deploy to be 'in support', but if anyone has compelling reasons to stay on 3.1 or .NET Framework then that shouldn't be hard until the codebase actually diverges.

I do feel that the stride preprocessor defines are overlapping with those being defined in .NET5. Following the work to make Stride compile and work correctly on .NET 5, I suggest removing all preprocessor defines in favour of those defined by .NET 5, looking into aligning those used for older TFM's with those defined in .NET 5 and to prefer runtime checks for the graphics API rather than preprocessor defines.

Finally I think it would be easy to adopt new targets, seeing how they now all use the same SDK and merely require some MSBuild properties to get set, and I would be very interested to see the project reunion type projects (WinUI on Desktop) become a new target that Stride supports. And MAUI, off course, when that will be usable - in favor of Stride's custom UI framework, at the very least to be able to use that, too.

[xen2]

I think I am mostly done with the prototype. Feel free to try it (from https://github.com/xen2/stride/tree/net5).

@ericwj thanks for the feedbacks.
I would also like to be able to get rid of MSBuild.Sdk.Extras and get back to a more standard building process.
It seems the two main blockers for that are:

• Switch to .NET 5.0 only (which should happen in 4.1) so that we don't need RuntimeIdentifiers for .NET Standard anymore
  This should remove all our complex steps related to RuntimeIdentifiers (we might need to unify some code between platforms before)
• Either wait for net6.0-android and net6.0-ios, or wait for Support additional target frameworks such as for Xamarin, UWP, etc dotnet/sdk#491 to be fixed, or embed the small part of MSBuild.Sdk.Extras to deal with that

In general, a lot of custom build steps & workaround are probably not necessary anymore and/or can be done in a nicer way.

[Perksey]

For Silk.NET, the solution to the MSBuild.Sdk.Extras was NUKE. Because dotnet build can’t build old-style projects, we just strip them out as part of the build process unless you a) have desktop MSBuild on your PC and b) have specified you want to build Android and iOS feature sets. However, I appreciate that sounds a bit convoluted. My personal opinion is just to wait until .NET 6. If Xamarin decide to push back mobile even further to .NET 7 then I guess we can revisit it.

…

On Wed, 25 Nov 2020 at 08:28, xen2 ***@***.***> wrote: I think I am mostly done with the prototype. Feel free to try it (from https://github.com/xen2/stride/tree/net5). @ericwj <https://github.com/ericwj> thanks for the feedbacks. I would also like to be able to get rid of MSBuild.Sdk.Extras and get back to a more standard building process. It seems the two main blockers for that are: - Switch to .NET 5.0 only (which should happen in 4.1) so that we don't need RuntimeIdentifiers for .NET Standard anymore This should remove all our complex steps related to RuntimeIdentifiers (we might need to unify some code between platforms before) - Either wait for net6.0-android and net6.0-ios, or wait for dotnet/sdk#491 <dotnet/sdk#491> to be fixed, or embed the small part of MSBuild.Sdk.Extras to deal with that — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#912 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVEYI2CQZKZGOLLGGHNSH3SRS53JANCNFSM4TXK56KA> .