BenchmarkDotNet package shouldn't depend on Microsoft.CodeAnalysis.CSharp

[olstakh]

Hi. Is there a reason that Microsoft.CodeAnalysis.CSharp nuget package is a dependency for BenchmarkDotNet? I don't see it being a runtime dependency, and it creates a conflict in repositories that have a code analysis project for their own needs.
The benchmark analyzers can just be a part of analyzers folder in BenchmarkDotNet package and will be applied automatically, but having a hard dependency on Microsoft.CodeAnalysis.CSharp is unclear to me, and results in conflicts

[filzrev]

As far as I've confirmed.
Microsoft.CodeAnalysis.CSharp package is used by following code.

1. RoslynToolchain
2. MonoAotToolchain (It internally using Generator of RoslynToolchain)
3. CompilationValidator::GetCsharpKeywords
4. StringAndTextExtesions::EscapeSpecialCharacter

It can avoid 3. and 4. by replace logics to custom implementation or source generator based code.

But 1./ 2. seems to be hard to remove Roslyn package dependency.
(It need custom build that remove unused toolchains)

[timcassell]

What is the error you get? Is it related to #2889? You get the error when you build your own project, or when BDN builds the generated project?

[olstakh]

@timcassell i don't think it's related. The error is on our end when we restore / build our repo after trying to upgrade BDN (which includes upgraded dependency on codeanalysis package that conflicts with ours). May be it is expected for BDN to use it at runtime as a dependency, in which case the issue can be closed. I just haven't seen such a runtime use case before

[timcassell]

How is your project set up? I would expect analyzer projects to not take a dependency on BenchmarkDotNet. Are you benchmarking the analyzer itself?

[olstakh]

@timcassell , yes, i have benchmarks for source generators (like to prove that my compile-time generated logging is faster than using logging extensions, etc)

Also, we're using CPM with Transitive Pinning, so msbuild complains early. This can be worked around using VersionOverride i'm guessing (i.e. we'll have to add a package reference to Microsoft.CodeAnalysis.* packages for all BDN projects with VersionOverride). Not ideal, but not blocking

[timcassell]

Are you referencing your source generator as a package with Microsoft.CodeAnalysis.CSharp as a runtime dependency? I wonder if you pack the source generator into your package directly under analyzers without taking a runtime dependency if it will fix it. See how we pack our analyzers for example

BenchmarkDotNet/src/BenchmarkDotNet.Annotations/BenchmarkDotNet.Annotations.csproj

Line 32 in 94303f4

<Content Include="..\BenchmarkDotNet.Analyzers\bin\$(Configuration)\**\*.dll" Pack="true" PackagePath="analyzers/dotnet/" Visible="false" />

[olstakh]

It's an inhouse project for our repo, not an external package. We don't ship it, so there's nothing to pack.
But the more i look at it - it's probably CPM + Transitive Pinning + ReferenceTrimmer combo that messes with us. I'll try explicitly adding Microsoft.CodeAnalysis.CSharp as a package reference for all BDN projects with version override to force a higher version. I'm sure ReferenceTrimmer will then start to complain about unused package reference, we'll have to suppress it. I'll give it a go

[timcassell]

So you're using project reference? Are you setting the ReferenceOutputAssembly, OutputItemType attributes?

BenchmarkDotNet/tests/Directory.Build.props

Line 9 in 94303f4

<ProjectReference Include="$(MSBuildThisFileDirectory)..\src\BenchmarkDotNet.Analyzers\BenchmarkDotNet.Analyzers.csproj" ReferenceOutputAssembly="false" OutputItemType="Analyzer" />

It seems that your project has Microsoft.CodeAnalysis.CSharp as a runtime dependency, which you expect it shouldn't, which causes the versioning error.

[olstakh]

@timcassell , no, there's no runtime reference from our benchmark project to Microsoft.CodeAnalysis.CSharp. The reason for failure is Central Package Management system + Transitive pinning. It can be mitigated by explicitly adding Microsoft.CodeAnalysis.* packages (around 4 or 5) with VersionOverride for each project that references BDN package.