Skip to content

Depend on Microsoft.CodeAnalysis 4.13.0#35753

Merged
roji merged 2 commits intodotnet:mainfrom
roji:CodeAnalysis
Mar 11, 2025
Merged

Depend on Microsoft.CodeAnalysis 4.13.0#35753
roji merged 2 commits intodotnet:mainfrom
roji:CodeAnalysis

Conversation

@roji
Copy link
Copy Markdown
Member

@roji roji commented Mar 8, 2025

Closes #34637

@roji roji marked this pull request as ready for review March 8, 2025 22:43
@roji roji requested review from a team, AndriySvyryd and maumar as code owners March 8, 2025 22:43
Comment thread test/Directory.Packages.props Outdated
<PackageVersion Include="Microsoft.CodeAnalysis.CSharp.Analyzer.Testing.XUnit" Version="$(MicrosoftCodeAnalysisTestingVersion)" />
<PackageVersion Include="Microsoft.CodeAnalysis.CSharp.CodeFix.Testing.XUnit" Version="$(MicrosoftCodeAnalysisTestingVersion)" />
<!-- See https://github.com/dotnet/roslyn-sdk/issues/1175 -->
<PackageVersion Include="Microsoft.CodeAnalysis.Analyzer.Testing" Version="1.1.3-beta1.24423.1" />
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use $(MicrosoftCodeAnalysisAnalyzerTestingVersion) and $(MicrosoftCodeAnalysisCSharpTestingVersion)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any value in actually doing that though? I'm noticing that we already sometimes specify versions inline Directory.Packages.props... Versions.props made a lot of sense for everything before Directory.Packages.props, but should Directory.Packages.props now be just the place where we specify all versions instead of having yet another layer of indirection?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can decide to remove Versions.props at some point (should be possible with VMR), but for now the rule of thumb is "if it's shipped by Microsoft it goes to Versions.props" mainly for consistency.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll do this to just move forward.

Though I again think we're needlessly adding protocol and ceremony to our processes. We already have various other Microsoft-shipped packages (SqlClient, Microsoft.Build.Locator, Microsoft.Azure.Cosmos) specified directly (and I'm not sure why Microsoft and non-Microsoft packages should be any different). I don't really care about completely removing Versions.props altogether (if it's necessary because of some Arcade thing), but for the packages where we can specify directly in Directory.Packages.props, Versions.props just seems to add another layer of indirection, another MSBuild identifier we have to make up and track... Just needless complexity.

Comment thread Directory.Packages.props
Comment thread Directory.Packages.props
@roji roji enabled auto-merge (squash) March 11, 2025 08:59
@roji roji merged commit ba7e7bc into dotnet:main Mar 11, 2025
@roji roji deleted the CodeAnalysis branch March 11, 2025 09:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Upgrade Microsoft.CodeAnalysis.* package versions to 4.13.0

2 participants