chore: consolidate 9 Roslyn-versioned project duplicates

[thomhurst]

Description

Each Roslyn version has an identical project with only the RoslynVersion property differing:

• TUnit.Core.SourceGenerator.Roslyn414
• TUnit.Core.SourceGenerator.Roslyn44
• TUnit.Core.SourceGenerator.Roslyn47
• TUnit.Analyzers.Roslyn414, .Roslyn44, .Roslyn47
• TUnit.AspNetCore.Analyzers.Roslyn414, .Roslyn44, .Roslyn47
• TUnit.Assertions.Analyzers.Roslyn414, .Roslyn44, .Roslyn47

Bug fixes must be replicated across 9+ separate projects, and risk becoming inconsistent.

Suggested Fix

Consolidate to a single project per analyzer/generator with RoslynVersion as a build parameter, or use conditional compilation.

[thomhurst]

@claude The code actually just lives in one library - Other projects just import the files with <Compile Include="... tags

[claude]

Claude finished @thomhurst's task in 2m 12s —— View job

---

Analysis

• Explore the project structure to understand the <Compile Include> setup
• Analyze the actual duplication and remaining friction
• Respond with findings

---

Thanks for the clarification! After exploring the codebase, I can see the structure is already quite clean.

Current Structure

Each Roslyn-versioned .csproj is a minimal stub — only 5–8 lines — with the only difference being the RoslynVersion property:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <RoslynVersion>4.14</RoslynVersion>
    </PropertyGroup>
    <Import Project="$(MSBuildThisFileDirectory)..\Analyzer.props" />
</Project>

The shared .props files (Analyzer.props, SourceGenerator.props, AspNetCore.Analyzer.props) handle everything else:

• <Compile Include="..\TUnit.Analyzers\**\*.cs" /> — links to shared source
• Imports Roslyn.props which translates RoslynVersion → Microsoft.CodeAnalysis.* version

Directory.Build.props sets assembly names, namespaces, etc. via project-name-prefix conditions.

Assessment

The issue description's concern about bug fixes needing replication across 9 projects doesn't apply in practice — code lives in one place. The 9 .csproj stubs are already minimal.

The remaining overhead when adding a new Roslyn version is:

1. Create a directory + 5-line .csproj
2. Add a project entry to TUnit.sln
3. Add a condition block to Directory.Build.props (if not already pattern-matched)

Could it be simplified further?

Theoretically you could eliminate the stub directories by using a single project with a custom MSBuild target that builds multiple times with different RoslynVersion values. However:

• MSBuild doesn't support this cleanly out of the box
• It would add significant build complexity for minimal gain
• Each build needs to produce a distinct output assembly for packaging

Given the stubs are already ~5 lines each, this issue could reasonably be closed as "by design" — the code duplication concern doesn't exist; only the project file stubs do, and those are already as minimal as MSBuild allows.