In Microsoft.CodeAnalysis.Collections, pin S.C.Immutable to 5.0.0 to allow prebuilt reduction downstream #57129
Comments
There is no such assembly. Microsoft.CodeAnalysis.Collections is a package containing only source code, and the consumer can reference any version of System.Collections.Immutable it desires.
This solution was carefully constructed to make this impossible. |
I'm referring to the project/package. The package has a package reference: It shows up in the nuspec as a nuget dependency, which influences the downstream project.
What part of that should be impossible? |
The downstream project can add an explicit reference to a newer version of System.Collections.Immutable, which will be used instead of the transitive dependency version.
Roslyn doesn't build anything for Microsoft.CodeAnalysis.Collections. It's a just a collection of source+resx files in a zip package.
Source build should not change dependency versions for Roslyn references. |
Ok, this was just semantics. I would say that Roslyn builds a zip package that contains the collection of source+resx files (and a nuspec).
That is what I'm proposing in this issue. |
👍
This is correct.
Updating the package can be tedious because of the way it integrates with arcade build customizations (specifically around resx/xlf content). It seems reasonable for MSBuild to auto-update this package, but I would not expect that update process to be tied to source build in any way. |
|
I think given the support limitations in dotnet/msbuild#6960 (comment) it would make sense for MSBuild to not auto-update. (Any problems would hopefully be caught by a PR validation error on the auto-update PR, I suppose those are more likely to be noise than something worth fixing just to get onto the latest version.) And actually, given closing dotnet/msbuild#6960, this issue isn't needed either. There's no need to build the Microsoft.CodeAnalysis.Collections nupkg in Roslyn during source-build if nobody auto-updates new versions of it when they take new versions of Roslyn. Closing. |
If source-build upgrades this from
5.0.0to6.0.0[-rc.2.[...]]:roslyn/src/Dependencies/Collections/Microsoft.CodeAnalysis.Collections.Package.csproj
Line 27 in 40a11ba
roslyn/eng/Versions.props
Line 259 in 40a11ba
then downstream, if dotnet/msbuild consumes
Microsoft.CodeAnalysis.Collectionsas built by dotnet/roslyn to remove a prebuilt dependency, dotnet/sdk then hits a build error when it consumes dotnet/msbuild packages:(Source-build does override it, because the package version follows the overridable convention.)
There are two ways to fix it without adding prebuilts:
System.Collections.Immutableversion from 5.0.0. Then whenMicrosoft.CodeAnalysis.Collectionsflows downstream, there's no 6.0.0 reference to worry about. 5.0.0 is already in SBRP, so this doesn't add any prebuilts.System.Collections.Immutableis used as reference only, but let me know if this is wrong.Microsoft.CodeAnalysis.Collectionsto SBRP as a source-only package and make sure dotnet/msbuild pins to that version.I'm trying out a patch that implements (1). From a source-build perspective, it's preferred: we wouldn't need to add any more stuff to SBRP or maintain it over time, and
Microsoft.CodeAnalysis.Collectionscould be maintained (by e.g. Red Hat) in a single place rather than having multiple versions to look at and patch.(2) could also be fine. It would result in a more similar source-build vs. Microsoft build--but that's only the status quo. Is it really intended that dotnet/msbuild never gets auto-updates to
Microsoft.CodeAnalysis.Collections? (@sharwell, do you have context, based on dotnet/msbuild#6595?)The text was updated successfully, but these errors were encountered: