Runtime: Cleanup TargetFrameworks from project that Reference System.Private.CoreLib

[safern]

There are some projects which don't have a OS specific implementation but they have a ReferenceFromRuntime into System.Private.CoreLib.

The way ReferenceFromRuntime works, is that it translates that reference to a reference to runtime.depproj which in the old days used to restore the coreclr runtime specific transport packages. Nowadays, we just get the coreclr assets from the live location of coreclr, so I think we shouldn't need to cross compile those projects anymore, for example:
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime/src/System.Runtime.csproj#L5
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Collections/src/System.Collections.csproj

cc: @ericstj @ViktorHofer @danmosemsft @Anipik

[msftbot[bot]]

Tagging @safern, @viktorhofer as an area owner

[ViktorHofer]

But don't we still multi-target runtime.depproj which means it resolves the runtime's assets based on the TargetFrameworkSuffix?

[safern]

But don't we still multi-target runtime.depproj which means it resolves the runtime's assets based on the TargetFrameworkSuffix?

Yeah, we still do, but I think that should be cleaned up. We should resolve corelib from the local location using TargetOS of the build, I don't think we need to cross target runtime.depproj for NetCoreAppCurrent, only for netcoreapp3.0.

[ViktorHofer]

I see, that makes sense. Do we care about netcoreapp3.0 in runtime.depproj, or let me rephrase, do we need to build the testhost for 3.0?

[safern]

Do we care about netcoreapp3.0 in runtime.depproj, or let me rephrase, do we need to build the testhost for 3.0?

It seems like we still use it: https://github.com/dotnet/runtime/blob/master/src/libraries/restore/runtime/runtime.depproj#L39

It seems like we use that to get the netcoreapp3.0 ref assemblies and build against that. Once we remove depprojs and use the SDK to get the ref assemblies we should be able to not build it for 3.0

[ViktorHofer]

OK that should be easy to do as I already have started with that work in a branch. I'll open a WIP PR later, maybe people want to contribute to it :)

[safern]

Sounds good, thanks 😄

[ericstj]

We should resolve corelib from the local location using TargetOS of the build

So doing this without a guaranteed contract for CoreLib feels like a lie. We are building something that we expect to work for all runtimes but building it against a single runtime. We also disallow the use of Target* properties in libraries projects since those can change without output paths changing resulting in incremental build problems.

Even though it’s a lie, it might be an acceptable one... @safern whats the worst you can imagine would happen due to this lie?

[safern]

Even though it’s a lie, it might be an acceptable one... @safern whats the worst you can imagine would happen due to this lie?

That is already the behavior. If you build on Windows, you're getting the Windows corelib because we're consuming the live built from the coreclr artifacts path, same behavior for Unix. Am I missing something?

[safern]

Also we’re lying even more because in the all configurations leg we’re cross compiling against the Windows version of corelib.

[ericstj]

Also we’re lying even more because in the all configurations leg we’re cross compiling against the Windows version of corelib.

That's actually a bug that was introduced with repo consolidation. It makes it impossible to build AllConfigurations when we have libraries that actually need to differ based on the surface area of CoreLib. This is what recently broke AllConfiguration on unix.

[safern]

That's actually a bug that was introduced with repo consolidation. It makes it impossible to build AllConfigurations when we have libraries that actually need to differ based on the surface area of CoreLib. This is what recently broke AllConfiguration on unix.

Yeah I know, what I'm saying is that we could remove the cross targeting because we're not cross targeting coreclr on the build that we are consuming, so if we cross target System.Runtime, we will still be using the same corelib for both targets because of the live build.

[ericstj]

we will still be using the same corelib for both targets because of the live build.

What if corelib cross-targeted as well?

[ericstj]

So that's one pathway, but I'm still open to doing what was originally suggested, we just need to understand what it would mean.

For example: how do we even build AllConfigurations if we never fix the problem we mention above? I don't see how we do it, the only reason it still works on Windows today is that the Windows CoreLib happens to be a superset of the linux CoreLib. If they happened to become disjoint, then we'd have no way of building AllConfigurations. We could solve that by "lying" about configurations in projects that reference CoreLib. Keep them runtime-agnostic, but still make them different based on TargetOS. This can work if the only place they ship is in the runtime-pack. Unfortunately today we do ship nuget packages which depend on these libraries (See System.Runtime.WindowsRuntime.*). Maybe we find a way to stop building those?

[ericstj]

/cc @jeffschwMSFT

[jeffschwMSFT]

Adding @AaronRobinsonMSFT regarding System.Runtime.WindowsRuntime.*

[AaronRobinsonMSFT]

@ericstj There is a possible plan to stop needing to ship System.Runtime.WindowsRuntime.* entirely. I am not entirely sure how to phrase these things, but with the work to support an alternative to built-in WinRT and instead rely entirely on a new tool (CsWinRT) this becomes possible since these assemblies won't have much utility in this new world. Hopefully the CsWinRT repo will be public soon and I can point to that. How pressing is the current issue?

[ericstj]

I noticed one thing that should be uncontroversial. Many of the projects that do this today have had all their types pushed down into System.Runtime. For those we can simply change them to build against references instead of CoreLib.

[ericstj]

Now System.Runtime.WindowsRuntime is removed this should be doable. I believe we can now assume that CoreLib surface area used by libraries is consistent across all runtimes. That will allow us to remove runtime-specific configurations from projects that don't actually differ by runtime but reference CoreLib. We can rely on CI to keep this honest, because API compat will catch the case where we're missing typeforwards, duplicate types, or are missing supporting API.

We can also clean up the runtime configuration assemblies where types were pushed down.

I think it makes sense for us to do a pass at this as it will help reduce this list for the WASM effort: https://github.com/dotnet/runtime/issues/37439#issuecomment-639069233

@Anipik can you help pick this up?