Add NetCoreAppCurrent configurations to every library that targets .NETStandard or .NETCoreApp #54012
Comments
ViktorHofer
added
design-discussion
|
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsWith 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 @marek-safar and @eerhardt especially expressed their interest in this. Here's the list of the 50 (source) libraries which don't have a cc @ericstj @Anipik @safern @stephentoub @jkotas
|
dotnet-issue-labeler
bot
added
the
untriaged
ViktorHofer
changed the title
ViktorHofer
removed
the
untriaged
|
You may be missing |
|
cc @davidfowl |
|
@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? |
|
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:
Cons:
With the recent added support for shipping |
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. |
|
cc @buyaa-n for the platform analyzer aspect of this discussion |
System.ComponentModel.Composition, System.Diagnostics.PerformanceCounter and System.Runtime.Caching. Helps with dotnet#54012
System.ComponentModel.Composition, System.Diagnostics.PerformanceCounter and System.Runtime.Caching. Helps with #54012
This should be an easy thing to measure and share (even if only an estimate based on a good heuristic). We could diff that with what was previously shipped (eg: before asset deprecation) to demonstrate the net result. Perhaps we can also extrapolate over time what it would look like given our support policy. One of the arguments against additional configurations in the past was unbounded package growth, now we're saying it's not unbounded, it's only X number of configurations for in-support .NET versions. It'd be nice to say what the total impact is to all impacted packages and back up our statement about overall impact being small.
While that characteristic isn't introduced with this change it does become more important as it's easier for folks to create differences between configurations. I can imagine this being important for libraries like System.Text.Encodings.Web, System.Text.Json, and Microsoft.Extensions.* where we're doing active feature development and would care about how those features function on older frameworks (that are still in support). I wonder what it would take to support downlevel test runs for these? I can imagine it's much cheaper now that helix has support for deploying frameworks and we build the tests in a way that they shouldn't depend on a custom shared framework. I really like this direction and I think it sets us up for an overall better maintainable codebase over future releases. @ViktorHofer it seems like this and some of your other changes work together to realize an overall vision for our targeting strategy over the lifetime of .NET 6.0 onward. Do you think it makes sense to record this in a vision/design doc? |
Easy as of that I just spent 4 hours collecting and analyzing the data, sure 😄. For the analysis I respected both the assemblies sizes as well as the documentation file sizes compressed. Please see the table below that provides data of the discussed packages. The size increase in the Microsoft.Extensions.* packages are expected as those didn't benefit from the removal of unsupported assets. In most cases we are seeing a size increase of < 100KB (i.e. Extensions packages). Packages which contain runtime specific assemblies are usually larger which is why sizes increases are larger for those. On the positive side, mose of those packages benefited very much from the "Remove unsupported frameworks" effort which is why the size diff when comparing with 5.0 is quite small. The biggest outliner is System.Data.OleDb which grow 2-3x (depending on NET 7 vs NET 8). That assemblies is quite big but also its documentation file is quite large.
|
Probably would make sense but do people still read design docs in 10+ years from now (/sarcasm)? Usually I prefer to put as much detail as possible into commit messages, PRs, issues and docs as those are preserved over time. I already mentioned to couple folks that I would like to present the versioning and packaging changes in a libraries teams specific talk. If there's still a need for a design document after that or if you explicitly want it to be written, I'm happy to do so. |
|
After 8.0 we assume the sizes are steady-state, right? Did any of the size differences surprise you or suggest that we should do things to reduce the size (like move to runtime checks from cross compilation)? Repo docs might serve the same purpose as design. Just hoping we can record what we do and why, and hopefully get a comprehensive view of everything that might be related so that we can be sure to deliver a complete story. Definitely the talk (and associated resources) could help. |
Correct. Every even major version, starting with 8.0, will carry along three NETCoreApp assets (if the project doesn't target rids and also exkluding ref assemblies) and every odd number two (LTS + Current). The one that stands out is OleDb but not because of it targeting rids but because of the overall assembly and public api (xml) size. We already know that there are a few OOBs that target many rids and are therefore quite large (i.e. Odbc) but those are already in main and aren't part of this specific discussion. |
|
The majority of libraries now have a net6.0 configuration and the remaining ones will get one in the main branch. Moving to 7.0. |
|
@maryamariyan @eerhardt I won't be around the next months but it would be great if we could stay on top of this and #43605 which in combination will enable nullability annotations and targeting the latest .NETCoreApp version for all the extensions projects. |
This makes all Extensions projects consistent in which TFMs they target. This way we don't need to add new TFMs during development of a new feature. Fix dotnet#54012
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
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
NetCoreAppCurrentconfiguration 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:cc @ericstj @Anipik @safern @stephentoub @jkotas
The text was updated successfully, but these errors were encountered: