SDK ships stale copies of .NET packages that are still being built

[ericstj]

Describe the bug

The SDK is shipping an old copy of a number of live built packages from runtime. I checked the SDK folder and task folders and found the following to be out of date:

• System.Collections.Immutable
• System.Reflection.Metadata
• System.Reflection.MetadataLoadContext
• System.ComponentModel.Composition

There may be more.

While I understand that the SDK might want to compile against older assemblies to enable sharing with a host like VS or roslyn - that's only the case when it's not shipping those. If it ships the assemblies it needs to ship the latest so that future servicing updates are picked up.

To Reproduce

Examine the file versions of the files redistributed in the SDK. Check for cases that are older than the packages produced in the same .NET release. (I have some tooling I'm working on to help automate this, but wanted to raise this first as it came up in a separate issue).

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[marcpopMSFT]

I'm not sure where System.ComponentModel.Composition is coming from as we don't have direct references to it and I wasn't able to find the transitive reference in the binlog or a deps.json. I can add it to the directory.packages.props and see if that lifts it up.

The other three are special cases and must stay in sync with msbuild/roslyn per my understanding. The last time I tried to update those, nothing worked. It's possible we're using the version override in more locations than we need but not sure which are unnecessary and if that would help.

We pin in the following places that I see:
toolset-tasks.csproj
razor.tasks.csproj
staticwebassets.tasks.csproj
msbuildsdkresolver.csproj
workloadmsbuildsdkresolver.csproj
Various test assemblies

@jaredpar @rainersigwald

[marcpopMSFT]

Pinning System.ComponentModel.Composition didn't work as it's coming from the testplatform package which doesn't get rebuilt in the sdk repo.

Pinging @nohwnd and @pavelhorak to take a look but from the binlog, this is the first copy I see:
Message Copying file from "<>.nuget\packages\microsoft.testplatform.cli\17.12.0-preview-24453-04\contentFiles\any\netcoreapp3.1\System.ComponentModel.Composition.dll" to "<>\artifacts\bin\redist\Debug\net9.0\System.ComponentModel.Composition.d...

Do ya'll know why the testplatform cli package appears to have a net3.1 version of this file and can that be updated (I only tested 9.0.100)?

[nohwnd]

we are building with netcoreapp3.1 target framework still. I think it is because of testhost needed to stay compatible with all the versions that VS still "supports".

will have a look on how we can update the cli package, so we don't ship outdated versions.