Fixing build for src/shims/manual to use appropriate configurations

[Anipik]

The build for manual shims against netcoreappaot is currently broken. This is due to the fact that some of projects use a different version of System.Private.CoreLib.
We can add netcoreappaot in all those projects but we have to verify that this is not interfering with other msbuild properties and items being defined.
The error can be reproduced by running build.cmd -f netcoreappaot

Build FAILED.

C:\git\corefx\artifacts\obj\mscorlib\netcoreappaot-Debug\mscorlib.Forwards.cs(1073,93): error CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. [C:\git\corefx\src\shims\manual\mscorlib.csproj]
C:\git\corefx\artifacts\obj\mscorlib\netcoreappaot-Debug\mscorlib.Forwards.cs(1073,12): error CS0012: The type 'Enum' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'. [C:\git\corefx\src\shims\manual\mscorlib.csproj]
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:03:27.72

The newGenfacades bring forward a lot of issues with manual facades. Some of them were handled in dotnet/corefx#36126 but in a little hacky way.

Manual shims have a dependency on System.Private.CoreLib as it uses some public types which are not exposed in the reference assembly.
me and @ericstj tried aliasing these types and removing the reference to System.Private.CoreLib while generating facades but the compiler doesn't allow aliasing of SPC

We require a new approach to handle these manual shims

@ericstj feel free to edit the description.

[ericstj]

@Anipik removed the netcoreappaot configurations with dotnet/corefx@e9d1a10.

The remaining problem here is that the manual shims build against implementation assemblies, which differ by TargetGroup & OSGroup but the manual shims only list TargetGroup in their configurations. As a "shortcut" they use the OSGroup of the overall BuildConfiguration when building the runtime path. This is still not correct as one could change the overall BuildConfiguration OSGroup, which in turn changes the inputs to the manual shims (producing different typeforwards) but the shims build to the same path.

To fix this we should either a) add configurations to the manual shims b) change the manual shims to build against references.

I think the right thing to do here would be to to a. To enforce it we can use ReferenceFromRuntime.

[ViktorHofer]

Make sure to also address feedback from https://github.com/dotnet/corefx/issues/21103

[ViktorHofer]

To fix this we should either a) add configurations to the manual shims b) change the manual shims to build against references.

Wouldn't switching to build the manual shims against references remove the necessity of the runtime directory? If yes I would prefer b.

[ericstj]

Runtime directory is still used by tests that use ReferenceFromRuntime I believe. Manual shims can't build against references today because we don't expose everything they need. We could add internal only types to the references and add internalsvisibleto to make that work...

[ViktorHofer]

@ericstj while triaging the untried issues I stumbled upon this. I noticed this as well in my local build. Giving this another thought I don't think we want to build the manual shims against the ref assemblies as we probably don't want to add the internals that we type forwarding to. Am I missing something here?

[ViktorHofer]

Based on our earlier discussion, there is value in being able to construct the shared framework without OOB libraries being built. If we do something about this issue we should keep that in mind.