Skip to content

Add Wolverine.SourceGeneration to slnx (supersedes #2575)#2592

Merged
jeremydmiller merged 2 commits intomainfrom
fix/2575-source-generation-project-in-slnx
Apr 26, 2026
Merged

Add Wolverine.SourceGeneration to slnx (supersedes #2575)#2592
jeremydmiller merged 2 commits intomainfrom
fix/2575-source-generation-project-in-slnx

Conversation

@jeremydmiller
Copy link
Copy Markdown
Member

Supersedes #2575 by @saithis. Their original commit is preserved verbatim with their authorship intact; this PR adds one follow-up commit on top to fix the resulting framework-pinned build failure.

What @saithis fixed

Wolverine.SourceGeneration.csproj is referenced from Wolverine.csproj as an analyzer (OutputItemType="Analyzer", ReferenceOutputAssembly="false") but was missing from wolverine.slnx, so the IDE solution view couldn't see it and a dotnet build wolverine.slnx would fail to find it. Adding the project to the slnx is the right call.

Why a follow-up commit was needed

After @saithis's add, dotnet build wolverine.slnx --framework net9.0 started failing with:

error NETSDK1005: Assets file '.../Wolverine.SourceGeneration/obj/project.assets.json'
doesn't have a target for 'net9.0'.

The analyzer project only targets netstandard2.0 (required for Roslyn analyzer loadability). Without --framework, MSBuild lets each project pick its own target framework and the analyzer builds happily. With --framework net9.0 pinned, MSBuild tries to build the analyzer for net9.0 too and there's no such target.

The follow-up commit marks the project Build="false" in the slnx — the same pattern already used for build/build.csproj. The project stays visible in the IDE solution view, but solution-level builds skip it. It still gets built whenever Wolverine.csproj is built, via the existing <ProjectReference OutputItemType="Analyzer" />, so nothing downstream changes.

Verification

  • dotnet build wolverine.slnx --framework net9.00 errors (was 1 NETSDK1005)
  • dotnet build src/Wolverine/Wolverine.csproj --framework net9.00 errors, 0 warnings (analyzer still attached and runs)
  • dotnet build wolverine.slnx (no framework) → 27 pre-existing OpenAPI sample-app errors, none related to this change

Test plan

  • Verify dotnet build wolverine.slnx --framework net9.0 succeeds
  • Verify Wolverine.csproj still uses SourceGeneration as an analyzer
  • No new errors compared to current main

🤖 Generated with Claude Code

saithis and others added 2 commits April 26, 2026 08:44
After GH-2575 added Wolverine.SourceGeneration to wolverine.slnx,
`dotnet build wolverine.slnx --framework net9.0` started failing with
NETSDK1005 because the analyzer project only targets netstandard2.0
(required for Roslyn analyzer loadability). The error doesn't appear in
unconstrained builds because the project naturally selects its single
TargetFramework, but CI and local commands that pin a framework hit it.

The project is already pulled in transitively as an analyzer via
Wolverine.csproj's ProjectReference (OutputItemType="Analyzer",
ReferenceOutputAssembly="false"), so it gets built whenever Wolverine
itself does. Marking it Build="false" in the slnx — same pattern used
for build/build.csproj — keeps it visible in the IDE solution view but
skips it from solution-level builds, sidestepping the framework
resolution mismatch.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

2 participants