Make .NET Framework and .NET Standard facade changes trackable

[ViktorHofer]

GenFacade is a tool that inspects a contract assembly's public API surface safe area, compares it with a passed in assembly closure and emits a C# source file with type forwards in it so that the satisfied API can be forwarded from the contract to the "implementation". GenFacades is used to construct the .NETFramework and the .NETStandard shim assemblies which live under src/libraries/shims/.

The generated source file isn't checked into the tree, it's placed into the project's intermediate output path. IMO it would help if we check these files into the tree so that any changes that impact shims - intentional or unintentional - are trackable. As an example, I just recently refactored how the shims are structured under src/libraries/shims and unintentionally removed a type forward from an assembly. I only noticed this regression by pure luck later.

The priority of this issue just rose because source build plans to remove their .NET Framework reference assembly packages during the .NET 8 release. That means that we can't automatically generate the type forwards during source-build. I will work on removing the dependency and check the type forwards in instead.

@dotnet/area-infrastructure-libraries @ericstj

[ghost]

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

Issue Details

---

GenFacade is a tool that inspects the satisfied and unsatisfied public API surface safe area based on a contract assembly and a passed in assembly closure. GenFacades is used to construct the .NETFramework and the .NETStandard shim assemblies which live under src/libraries/shims/.

The generated source file isn't checked into the tree, it's placed into the project's intermediate output path. IMO it would help if we check these files into the tree so that any changes that impact shims - intentional or unintentional - are trackable. As an example, I just recently refactored how the shims are structured under src/libraries/shims and unintentionally removed a type forward from an assembly. I only noticed this regression by pure luck later.

Additionally, adding the generated type-forward files to the tree would make it possible to construct the shims during the "libs.sfx" subset and later then, when the closure to compute the type forwards is complete during the "libs.oob" subset, invoke GenFacades to make sure that the generated files are up-to-date.

@dotnet/area-infrastructure-libraries @ericstj

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ViktorHofer]

The priority of this issue just rose because source build plans to remove their .NET Framework reference assembly packages during the .NET 8 release. That means that we can't automatically generate the type forwards during source-build. I will work on removing the dependency and check the type forwards in instead.

cc @NikolaMilosavljevic @MichaelSimons

[carlossanlop]

@ViktorHofer for my own education, would you mind telling me why the last sentence was struck through? Why does this not apply anymore?

Additionally, adding the generated type-forward files to the tree would make it possible to construct the shims during the "libs.sfx" subset and later then, when the closure to compute the type forwards is complete during the "libs.oob" subset, invoke GenFacades to make sure that the generated files are up-to-date.

[ViktorHofer]

Checking in the type forwards avoids calculating them at build time but you still need a resolvable target type that is pointed to, i.e. System.Text.RegularExpressions.dll for typeof(System.Text.RegularExpressions.Regex) (which lives in System.dll in .NET Framework).

I previously was under the impression that we can compile these type forwards without having the target type assemblies available which isn't true.