Depend on Microsoft.CodeAnalysis 4.13.0 #35753
Conversation
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" /> |
There was a problem hiding this comment.
Use $(MicrosoftCodeAnalysisAnalyzerTestingVersion) and $(MicrosoftCodeAnalysisCSharpTestingVersion)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Closes #34637