Remove package pulled by SBRP (microsoft.win32.registry)

[JanKrivanek]

Question: How do I make sure that a specific package contained within source-build-reference-packages (in this case microsoft.win32.registry) is not being referenced by sourcebuild?

Background: I'm trying to subscribe MSBuild to latest updates of SRBP, the update (sample PR here: dotnet/msbuild#8893) is however blocked on conflicting types from microsoft.win32.registry. This package is only needed when building NETStandard. For Core and FullFW, the types are within mscorlib, hence the sourcelib fails with:

/__w/1/s/artifacts/source-build/self/src/src/Build/Utilities/RegistryKeyWrapper.cs(201,17): error CS0433: The type 'RegistryKey' exists in both 'Microsoft.Win32.Registry, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' [/__w/1/s/artifacts/source-build/self/src/src/Build/Microsoft.Build.csproj]

So the types from package needs to be somehow excluded.

[MichaelSimons]

@JanKrivanek - Where does the reference to Microsoft.Win32.Registry come from? I see it is conditioned out in Microsoft.Build.Framework and Microsoft.Build.Tasts for non-NetStandard configurations? Is this brought in transitively? All nuspec references in SBRP appear to be scoped to .NETStandard2.0 as well. I am trying to understand how the source-build is differing from the MSFT build.

[JanKrivanek]

Thanks @MichaelSimons for looking into this. The reference was pulled in during net472 build of Microsoft.Build.csproj.
I'll have more detailed look into binlogs tomorrow to track down the difference

[MichaelSimons]

Ah, because msbuild is still on a 6.0 version of arcade, the repo source-build leg is probably not filtering out the 4.* tfms. There are likely other issues that will be hit while trying to update the SBRP reference to an 8.0 version because we removed all 4.* tfms. What is the blocker/timeframe on updating the arcade version?

FYI - @mmitche

[JanKrivanek]

There was an attempt to do so: dotnet/msbuild#8672 but probably turned out to be more involved. So it sounds like we need to pick up and finish that effort in order to unblock the update of SBRP to v8.0 - correct?

FYI - @rainersigwald (will add the upgrade to arcade 8.0 to kitten backlog)

[MichaelSimons]

So it sounds like we need to pick up and finish that effort in order to unblock the update of SBRP to v8.0 - correct?

Yes