.NET 6.0 experimentation #1002
Draft
.NET 6.0 experimentation #1002
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
xPaw
reviewed
Jan 7, 2022
| /// <see cref="CreateService{TService}"/> has been called with the same TService parameter. | ||
| /// </summary> | ||
| /// <typeparam name="TService">The type of a service interface.</typeparam> | ||
| public void RegisterService<[DynamicallyAccessedMembers( Trimming.ForProtobufNet )] TService>() |
There was a problem hiding this comment.
Does this actually help with trimming?
There was a problem hiding this comment.
I think it should but I never got it working end to end trimmed anyway, never quite got past logon.
|
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? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.0is the successor tonetstandard2.1andnet6.0naturally follows on from that. A library built targetingnet6.0is 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 ofnet6.0-iosandnet6.0-androidetc.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).