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

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.