Make private runtime-only dependencies on .NET Standard 2.0.

[teo-tsirpanis]

Context

Since #6148 we produce only reference assemblies for .NET Standard 2.0, which means that several of the our NuGet packages' dependencies when targeting .NET Standard 2.0 are unused.

Changes Made

The project files for Microsoft.Build.Framework, Utilities.Core and Tasks were updated to apply PrivateAssets="all" to all package references that are not exposed in the package's public API, when targeting .NET Standard 2.0.

Testing

I ran dotnet pack on these projects and validated manually that on .NET Standard 2.0, Microsoft.Build.Framework has zero dependencies, Utilities.Core depends only on Framework, and Tasks depends only on the previous two.

Because Roslyn keeps some internal APIs in reference assemblies, these reference assemblies still reference some assemblies whose respective package is not depended upon. I manually validated with ILSpy that the types in these assemblies are used only by internal APIs.

Notes

This is going to be a (minor) source-breaking change if a .NET Standard 2.0 project uses APIs from on one of the removed packages and transitively depended on it. They will have to directly depend on them, and it's not the first time we do a change like this (#9055).

I don't think that this is a binary-breaking change because the .NET Standard 2.0 binaries are not being used at runtime.

[rainersigwald]

Nice, I've been planning to do something like this (and likely even going further). Will look shortly.

[teo-tsirpanis]

and likely even going further

Let me know how further this can go, happy to do it now or in a subsequent PR.

[JanProvaznik]

sorry for letting this be stale for such a long time. The spirit of the change is good, though it breaks CI now (not sure if it ever passed or just accumulated divergence from December). @teo-tsirpanis are you interested in finishing it?

[teo-tsirpanis]

This failure is interesting:

There was a conflict between "System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.Memory, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
    "System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.Memory, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.
    References which depend on "System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [D:\a\1\s\.packages\system.memory\4.5.5\lib\netstandard2.0\System.Memory.dll].
        D:\a\1\s\.packages\system.memory\4.5.5\lib\netstandard2.0\System.Memory.dll
          Project file item includes which caused reference "D:\a\1\s\.packages\system.memory\4.5.5\lib\netstandard2.0\System.Memory.dll".
            D:\a\1\s\.packages\system.memory\4.5.5\lib\netstandard2.0\System.Memory.dll
    References which depend on or have been unified to "System.Memory, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [].
        D:\a\1\s\artifacts\bin\Microsoft.Build.Framework\Debug\netstandard2.0\Microsoft.Build.Framework.dll
          Project file item includes which caused reference "D:\a\1\s\artifacts\bin\Microsoft.Build.Framework\Debug\netstandard2.0\Microsoft.Build.Framework.dll".
            D:\a\1\s\artifacts\bin\Microsoft.Build.Framework\Debug\netstandard2.0\Microsoft.Build.Framework.dll
            D:\a\1\s\artifacts\bin\Microsoft.Build.Utilities\Debug\netstandard2.0\Microsoft.Build.Utilities.Core.dll
        D:\a\1\s\artifacts\bin\Microsoft.Build.Utilities\Debug\netstandard2.0\Microsoft.Build.Utilities.Core.dll
          Project file item includes which caused reference "D:\a\1\s\artifacts\bin\Microsoft.Build.Utilities\Debug\netstandard2.0\Microsoft.Build.Utilities.Core.dll".
            D:\a\1\s\artifacts\bin\Microsoft.Build.Utilities\Debug\netstandard2.0\Microsoft.Build.Utilities.Core.dll

Could it be because we inject references to specific versions of maintainenance packages in test projects?

[teo-tsirpanis]

@JanProvaznik CI is now green.

Most failures were due to my moving of the Microsoft.CodeAnalysis.Collections dependency to Build; that package had its own Strings.resx file, which caused name clashes with Build's own Strings.resx (Framework didn't have a Strings.resx, hence no clashes).

The solution is to update MS.CA.C to a version with dotnet/roslyn#78576, but because it is a more involved change, I rolled back that commit for now, and opened #12161.