Add NetCoreAppCurrent configurations to every library that targets .NETStandard or .NETCoreApp

[ViktorHofer]

With the evolution of .NET (net5.0 and above), building .NETCoreApp libraries becomes more important as they benefit from features like linking, compiler optimizations and the platform analyzer which is not enabled in dotnet/runtime for .NETStandard and .NETFramework tfms. To go even further, nullability warnings are more mature when targeting the very latest .NETCoreApp configuration and newer APIs become available to target which are often more efficient or easier to read. An example of such an API is the string.Contains usage over string.IndexOf which .NET even warns about now. Last but not least this avoid the need to reference the netstandard shim which means we don't cross assembly universes.

I propose to add a NetCoreAppCurrent configuration to any library that doesn't have one and targets .NETStandard or .NETCoreApp. Please note that this won't increase the overall build times as by default, only the best applicable tfm is built per project in a traversal build. That said, when building an individual library, build times will increase slightly as filtering doesn't happen there.

@marek-safar and @eerhardt especially expressed their interest in this.

Here's the list of the 49 libraries which don't have a NetCoreAppCurrent (and neither any .NETCoreApp) configuration:

• Microsoft.Extensions.Caching.Abstractions
• Microsoft.Extensions.Caching.Memory
• Microsoft.Extensions.Configuration
• Microsoft.Extensions.Configuration.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.Extensions.Configuration.CommandLine
• Microsoft.Extensions.Configuration.EnvironmentVariables
• Microsoft.Extensions.Configuration.FileExtensions
• Microsoft.Extensions.Configuration.Ini
• Microsoft.Extensions.Configuration.Json
• Microsoft.Extensions.Configuration.UserSecrets
• Microsoft.Extensions.Configuration.Xml
• Microsoft.Extensions.DependencyInjection
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.DependencyInjection.Specification.Tests
• Microsoft.Extensions.DependencyModel
• Microsoft.Extensions.FileProviders.Abstractions
• Microsoft.Extensions.FileProviders.Composite
• Microsoft.Extensions.FileProviders.Physical
• Microsoft.Extensions.FileSystemGlobbing
• Microsoft.Extensions.Hosting
• Microsoft.Extensions.Hosting.Abstractions
• Microsoft.Extensions.Hosting.Systemd: Consume PosixSignal in Hosting.Systemd's SystemdLifetime #59880
• Microsoft.Extensions.Hosting.WindowsServices
• Microsoft.Extensions.Http
• Microsoft.Extensions.Logging
• Microsoft.Extensions.Logging.Configuration
• Microsoft.Extensions.Logging.Debug
• Microsoft.Extensions.Logging.EventLog
• Microsoft.Extensions.Logging.TraceSource
• Microsoft.Extensions.Options
• Microsoft.Extensions.Options.ConfigurationExtensions
• Microsoft.Extensions.Options.DataAnnotations
• Microsoft.Win32.Registry.AccessControl: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.ComponentModel.Composition.Registration: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Composition.AttributedModel: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Composition.Convention: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Composition.Hosting: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Composition.Runtime: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Composition.TypedParts: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Data.OleDb: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.IO.Packaging: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.IO.Ports Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Memory.Data: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Net.Http.WinHttpHandler: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Numerics.Tensors: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Reflection.Context: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Resources.Extensions: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544
• System.Threading.AccessControl: Add NetCoreAppCurrent configuration to libs (Phase 1) #54544

cc @ericstj @Anipik @safern @stephentoub @jkotas

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With the evolution of .NET (net5.0 and above), building .NETCoreApp libraries becomes more important as they benefit from features like linking, compiler optimizations and the platform analyzer which is not enabled in dotnet/runtime for .NETStandard and .NETFramework tfms. To go even further, nullability warnings are more mature when targeting the very latest .NETCoreApp configuration and newer APIs become available to target which are often more efficient or easier to read. An example of such an API is the string.Contains usage over string.IndexOf which .NET even warns about now. Last but not least this avoid the need to reference the netstandard shim which means we don't cross universes anymore.

I propose to add a NetCoreAppCurrent configuration to any library that doesn't have one and targets .NETStandard or .NETCoreApp. Please note that this won't increase the overall build times as by default, only the best applicable tfm is built per project in a traversal build. That said, when building an individual library, build times will increase slightly as filtering doesn't happen there.

@marek-safar and @eerhardt especially expressed their interest in this.

Here's the list of the 50 (source) libraries which don't have a NetCoreAppCurrent (and neither any .NETCoreApp) configuration:

Microsoft.Extensions.Caching.Abstractions
Microsoft.Extensions.Caching.Memory
Microsoft.Extensions.Configuration
Microsoft.Extensions.Configuration.Abstractions
Microsoft.Extensions.Configuration.Binder
Microsoft.Extensions.Configuration.CommandLine
Microsoft.Extensions.Configuration.EnvironmentVariables
Microsoft.Extensions.Configuration.FileExtensions
Microsoft.Extensions.Configuration.Ini
Microsoft.Extensions.Configuration.Json
Microsoft.Extensions.Configuration.UserSecrets
Microsoft.Extensions.Configuration.Xml
Microsoft.Extensions.DependencyInjection
Microsoft.Extensions.DependencyInjection.Abstractions
Microsoft.Extensions.DependencyInjection.Specification.Tests
Microsoft.Extensions.DependencyModel
Microsoft.Extensions.FileProviders.Abstractions
Microsoft.Extensions.FileProviders.Composite
Microsoft.Extensions.FileProviders.Physical
Microsoft.Extensions.FileSystemGlobbing
Microsoft.Extensions.Hosting
Microsoft.Extensions.Hosting.Abstractions
Microsoft.Extensions.Hosting.Systemd
Microsoft.Extensions.Hosting.WindowsServices
Microsoft.Extensions.Http
Microsoft.Extensions.Logging
Microsoft.Extensions.Logging.Configuration
Microsoft.Extensions.Logging.Debug
Microsoft.Extensions.Logging.EventLog
Microsoft.Extensions.Logging.TraceSource
Microsoft.Extensions.Options
Microsoft.Extensions.Options.ConfigurationExtensions
Microsoft.Extensions.Options.DataAnnotations
Microsoft.Win32.Registry.AccessControl
System.ComponentModel.Composition.Registration
System.Composition.AttributedModel
System.Composition.Convention
System.Composition.Hosting
System.Composition.Runtime
System.Composition.TypedParts
System.Data.OleDb
System.IO.Packaging
System.IO.Ports
System.Memory.Data
System.Net.Http.WinHttpHandler
System.Numerics.Tensors
System.Reflection.Context
System.Resources.Extensions
System.Security.Cryptography.Xml
System.Threading.AccessControl

cc @ericstj @Anipik @safern @stephentoub @jkotas

Author:	ViktorHofer
Assignees:	-
Labels:	Design Discussion, area-Infrastructure-libraries
Milestone:	6.0.0

[jkotas]

You may be missing System.IO.Hashing that is recent addition and does not have NetCoreAppCurrent. (It has net6.0 that is not the same thing.)

[jkotas]

cc @davidfowl

[ericstj]

@ViktorHofer you talk about some of the benefits the .NET team may see by adding these configurations. What is the impact to our customers? What benefits will they see by us doing this, and are there any downsides?

[ViktorHofer]

Some of the advantages that are listed in the top post are observable by customers as well but let me exclusively list the pros and cons for customers.

Pro:

• Better nullability annotations based on nullability warnings being more mature on NetCoreAppCurrent than on .NETStandard.
• Being able to use APIs which are only available on the very latest and greatest version of .NETCoreApp
• NetCoreAppCurrent compiled assemblies should be more efficient than .NETStandard ones as more efficient APIs can be used under the shell and because of compiler optimizations that aren't available on .NETStandard.
• Something that I discussed with @eerhardt offline and which he believes shouldn't be neglected is the reduced amount of infrastructure maintenance. Community members usually don't know which references they need to add to satisfy a new build configuration and by adding the configurations as part of the repository versioning, that's already handled. Of course this doesn't exclusively apply to community members, we ourselves often struggle with adding new configurations. Ultimately that results in more time for feature and productivity work which should have a positive impact on our customers.
• Probably hard to measure but by not requiring the netstandard.dll shim, less type forwarding is happening during runtime.

Cons:

• Bigger packages. For most of the packages listed above, usually an increase of few KB - i.e. Microsoft.Extensions.FileSystemGlobbing.dll is 37KB small. There are of course exceptions when libraries target multiple rids.
• Not something that is introduced by this change but an overall concern: The .NETStandard configuration in the packages becomes untested as currently there's no suitable tfm in our test matrix that would pick the .NETStandard asset over the .NETCoreApp one. That of course opens the question what the .NETStandard implementation assembly is used for as .NETCoreApp and .NETFramework tfms are available which are preferred during runtime.

With the recent added support for shipping NetCoreAppCurrent assets in packages and being able to validate them in the packaging system together with the defined package support policy that dotnet/runtime now adheres I believe the pros
outweigh the cons.

[eerhardt]

opens the question what the .NETStandard implementation assembly is used for as .NETCoreApp and .NETFramework tfms are available which are preferred during runtime

Xamarin, Unity, UWP, etc. That list will get smaller over time, but there are other runtimes that aren't core or desktop that get used today.

[ViktorHofer]

cc @buyaa-n for the platform analyzer aspect of this discussion