[am11]

Branch illink-os-substitutions (eee2675) compared to main (a81c879), linux-x64, -c Release.

Library	main	PR	Diff
System.Diagnostics.Process	158,720	158,208	−512
System.Formats.Tar	106,496	105,984	−512
System.IO.Compression	188,416	187,904	−512
System.IO.FileSystem.DriveInfo	38,912	38,400	−512
System.Net.Http	579,584	579,072	−512
System.Net.NameResolution	93,184	92,672	−512
System.Net.Ping	41,984	40,960	−1,024
System.Net.Quic	154,624	150,528	−4,096
System.Net.Security	370,688	369,664	−1,024
System.Security.Cryptography	1,129,472	1,125,376	−4,096
Total (all DLLs)	34,301,952	34,288,640	−13,312

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

cc @jkotas #132218 (comment)

[agocke]

Rather than generating substitutions, if we think this is valuable we should implement these checks as proper feature switches.

[jkotas]

these checks as proper feature switches.

How would that work? The values are not user configurable. They are controlled by the runtime environment.

Note that this is just for netcoreapp libraries build that trims individual assemblies and uses reference assemblies for dependencies. This mode is special and comes with number of quirks. I think an alternative way to fix this would be to make this mode less special and reference implementation assemblies when trimming netcoreapp libraries. I suspect it would be more complicated change.

[am11]

How would that work? The values are not user configurable. They are controlled by the runtime environment.

I had two versions of this change, one this, the other for all ref assemblies without the user appcontext switches, but it is a bit noisy change (we need to collect all assemblies in shared framework). I can stage it if that is preferred.

[agocke]

How would that work? The values are not user configurable. They are controlled by the runtime environment.

I was imagining that it work just like the subsitutions defined above -- instead of encoding manual substitution XML entries we would define [FeatureSwitchDefinition] for each of the OS helper methods, then functionally we would pass the same --feature flags during library trimming as encoded by the OS compat table. This would avoid using the XML substitution backend.

But I forgot that FeatureSwitchDefinition is only valid for properties, so we can't use it without a new parameterless method feature.

[am11]

Alternative: #136495