Allow Microsoft.CodeAnalysis.Collections to be updated by source-build so it isn't a prebuilt dependency

[dagood]

This version is not overridable by source-build:

msbuild/eng/Packages.props

Line 12 in 15e80d5

<PackageReference Update="Microsoft.CodeAnalysis.Collections" Version="4.0.0-4.21379.20" />

The package is source-only, so it could be put into SBRP as a text-only package, but it costs manual maintenance whenever a new version comes along. If we just let source-build upgrade it, msbuild can use the "live" version produced by roslyn.

To make the Microsoft build consistent with upgrades, it seems like it would make sense to also hook this package up to Maestro++ dependency flow, to get updates in the Microsoft build as well. I don't see anything in #6595 pointing out reasons this package shouldn't be auto-updated.

Making this change as a patch makes dotnet/msbuild build without prebuilts, locally.

diff --git a/eng/Packages.props b/eng/Packages.props
index eb0144f9b..0f478634f 100644
--- a/eng/Packages.props
+++ b/eng/Packages.props
@@ -9,7 +9,7 @@
     <PackageReference Update="LargeAddressAware" Version="1.0.5" />
     <PackageReference Update="Microsoft.Build.NuGetSdkResolver" Version="$(NuGetBuildTasksVersion)" />
     <PackageReference Update="Microsoft.CodeAnalysis.Build.Tasks" Version="$(MicrosoftNetCompilersToolsetVersion)" />
-    <PackageReference Update="Microsoft.CodeAnalysis.Collections" Version="4.0.0-4.21379.20" />
+    <PackageReference Update="Microsoft.CodeAnalysis.Collections" Version="$(MicrosoftCodeAnalysisCollectionsPackageVersion)" />
     <PackageReference Update="Microsoft.CodeQuality.Analyzers" Version="3.3.0" PrivateAssets="all" />
     <PackageReference Update="Microsoft.DotNet.GenAPI" Version="2.1.0-prerelease-02404-02" />
     <PackageReference Update="Microsoft.DotNet.XUnitExtensions" Version="$(MicrosoftDotNetXUnitExtensionsVersion)" />
diff --git a/eng/Versions.props b/eng/Versions.props
index 7c66217f4..a356b7df0 100644
--- a/eng/Versions.props
+++ b/eng/Versions.props
@@ -26,6 +26,7 @@
   <!-- Production Dependencies -->
   <PropertyGroup>
     <SystemResourcesExtensionsPackageVersion>4.6.0</SystemResourcesExtensionsPackageVersion>
+    <MicrosoftCodeAnalysisCollectionsPackageVersion>4.0.0-4.21379.20</MicrosoftCodeAnalysisCollectionsPackageVersion>
   </PropertyGroup>
   <!-- Toolset Dependencies -->
   <PropertyGroup>

[rainersigwald]

@sharwell is there any reason not to also set up a subscription so we get the latest ~weekly?

[sharwell]

There is no compatibility assurances between releases. Roslyn is free to make changes including but not limited to:

• API changes
• Changes to LangVersion requirements
• Changes to target framework requirements
• Changes to project configuration requirements

Automated package substitution is (by design) not a supported scenario.

[sharwell]

More generally, source package substitution in source build is blanket disallowed, as it forces source build to produce outputs that do not match production. (If source build doesn't build the actual product from source, what's the point?)

[dagood]

Filed dotnet/source-build#2517 to add this particular version to SBRP instead.

[dagood]

More generally, source package substitution in source build is blanket disallowed, as it forces source build to produce outputs that do not match production. (If source build doesn't build the actual product from source, what's the point?)

It's not disallowed in general. This is a challenge that source-build has been grappling with since day one. Not having to make changes is a goal, but the .NET SDK simply isn't designed to be able to reasonably build from source like other ecosystems' tools are.

The point is building an SDK with the minimal feature gap vs. the Microsoft-built SDK using a process that can deliver servicing releases on time.