SteamKit icon indicating copy to clipboard operation
SteamKit copied to clipboard

.NET 6.0 experimentation

Open yaakov-h opened this issue 3 years ago • 1 comments

Leaving this up here for comments and because it's a direction I'd like to pursue in the long term.

This is relying on preview build on .NET 6, the first stable release is expected in November. This will be the next LTS build, so it will be supported for 3 years.

net5.0 is the successor to netstandard2.1 and net6.0 naturally follows on from that. A library built targeting net6.0 is still cross-platform and multi-runtime now that the various runtimes are all being merged into .NET - it will still run on .NET (formerly .NET Core) on all platforms, which should include the new Xamarin-derived targets of net6.0-ios and net6.0-android etc.

I have done no such testing on those new mobile .NET runtimes.

Microsoft are evolving things in lock-step now, so you basically need to target the new runtime in order to (a) get new language features, (b) get new attributes that control features such as nullability and trimming (without having to manually keep a copy of them), (c) get access to new runtime APIs, and (d) get access to new analyzer warnings that highlight deficiencies in code quality, as these can sometimes only be fixed with a mixture of (a)/(b)/(c).

I have kept a .NET Standard 2.0 built but there are optimizations I would like to make that require upgrading our build target to a more modern Core/5/6 runtime. In some cases these can be done via importing Microsoft's polyfill NuGet packages (they used to have a fancier name for this) but it can be problematic at runtime and a total PITA to manage.

I think we should provide a transition window, and then after a few releases it may be safe to drop the .NET Standard 2.0 build, which would mean dropping support entirely for .NET Framework.

With regards to .NET >= 5 specifically, it looks like protobuf-net have put in some effort regarding trimming, but the way I wrote SteamUnifiedMessages - with a very heavy dependency on Reflection - means that we can't trim well unless we rewrite SteamUnifiedMessages, which will be a limiting factor of how well DepotDownloader can be trimmed (among other users).

yaakov-h avatar Jul 04 '21 08:07 yaakov-h

Do you want to merge the non-trimming related commits now that NET6 is LTS?

EDIT: I guess you did in #1049, in which case this PR needs to be rebased?

xPaw avatar Jan 24 '23 19:01 xPaw