Project analysis fails ("No project found") unless TargetFramework is written literally in the test .csproj — an inherited or $(…)-referenced value is not seen

[PhilipThyregod]

`

Describe the bug

Stryker's project analysis returns zero projects — and fails with No project found, check settings and ensure project file is not corrupted / Failed to analyze project builds. Stryker cannot continue. (exit 1) — whenever the test project's TargetFramework is not written literally in the .csproj file itself.

The property being in effect is not enough. In every failing case below the project restores, builds and tests normally, and dotnet msbuild <proj> -getProperty:TargetFramework prints net10.0 correctly. Only Stryker cannot see it.

Measured on a single fixture, changing one thing at a time, with a green dotnet build asserted immediately before every Stryker run:

where TargetFramework comes from | dotnet build | -getProperty:TargetFramework | Stryker -- | -- | -- | -- literal in the .csproj | ✅ | net10.0 | ✅ scores normally inherited from a parent-directory Directory.Build.props | ✅ | net10.0 | ❌ No project found a Directory.Build.props in the same directory as the .csproj | ✅ | net10.0 | ❌ No project found $(SliceTargetFramework) in the .csproj, value from Directory.Build.props | ✅ | net10.0 | ❌ No project found

The last two rows are the interesting ones:

• it is not about import-chain depth — a props file sitting next to the project fails too;
• and a property reference in the csproj fails where the identical literal succeeds, which suggests the project file is being inspected textually rather than evaluated.

That last row also rules out the natural workaround for repositories that centralise the framework version: you cannot keep a single source of truth in Directory.Build.props and reference it from the test project.

To reproduce

mkdir repro && cd repro
cat > Directory.Build.props <<'EOF'

<Project>

<PropertyGroup>

<TargetFramework>net10.0</TargetFramework>

</PropertyGroup>

</Project>

EOF
dotnet new classlib -n Lib   -o Lib

dotnet new mstest   -n Tests -o Tests

cd Tests && dotnet add reference ../Lib/Lib.csproj

Then remove the <TargetFramework> line from Tests/Tests.csproj so it is inherited from Directory.Build.props (add a mutable method + a test to Lib first so there is something to score).

dotnet build                      # succeeds

dotnet test                       # succeeds

dotnet msbuild Tests.csproj -getProperty:TargetFramework    # prints net10.0

dotnet-stryker -p <abs path>/Lib/Lib.csproj -r Json --skip-version-check

→ Analyzing 1 test project(s). → No project found ... → exit 1.

Put <TargetFramework>net10.0</TargetFramework> back into Tests.csproj, change nothing else, and the identical command scores normally.

Logs

-L produces no analyzer detail — this is the complete relevant portion at -L -V trace, and --diag adds nothing further:

[DBG] Analyzing "Tests.csproj"

[VRB] No analyzer results to log. This indicates an early failure in analysis, check log file for details.

[DBG] Analysis of project "Tests.csproj" succeeded.

[DBG] Analyzing 0 projects.

[WRN] No project found, check settings and ensure project file is not corrupted.

Two observations about this output, offered as diagnosability feedback rather than as the bug:

• Analysis of project "Tests.csproj" succeeded. is logged even though the analysis produced zero results and the run is about to abort.
• check log file for details points at a log that contains no such details. The underlying MSBuild/analyzer failure is discarded, which makes this class of problem very hard to diagnose — the same No project found is also what you get when the test project simply fails to build, or when a referenced project fails to restore, so three unrelated causes are indistinguishable from the output.

A note on instrumentation, in case it saves someone time: setting MSBUILDDEBUGENGINE=1 to capture a binlog changes the outcome — a fixture that otherwise scores fine then fails with this same error, and the captured binlog shows an SDK-resolution failure against a Visual Studio MSBuild directory that is not what the uninstrumented run does. So binlog capture is not a safe probe for this.

Expected behavior

TargetFramework should be picked up however MSBuild resolves it — from Directory.Build.props, from a property reference, or from any other import — since the project is otherwise perfectly buildable and testable. Failing that, the error should name the missing/unresolved property instead of the generic No project found.

Desktop (please complete the following information):

• OS: Windows 11 Pro 26200
• Type of project: core (SDK-style, net10.0)
• Framework Version: .NET 10 (SDK 10.0.302); MSTest 4.0.2
• Stryker Version: 4.16.0 (global tool)

Additional context

Ruled out as causes, each tested individually against a green baseline: Microsoft.NET.Sdk.Web and Microsoft.NET.Sdk.Razor project references; .slnx vs no solution file; Central Package Management (with and without transitive pinning); global.json SDK pinning; a solution-local NuGet.Config that clears inherited sources; TreatWarningsAsErrors + EnforceCodeStyleInBuild; IsPackable/IsTestProject; a large test package set (coverlet.collector, Shouldly, NSubstitute, bUnit, NetArchTest.Rules); and multiple project references. With a literal TargetFramework all of those combinations analyze fine.

Also tested and ineffective as workarounds: --target-framework net10.0, -tp <test csproj>, both together, and --msbuild-path pointed at the SDK's own MSBuild. There appears to be no CLI-side way to compensate, which is awkward for tooling that invokes Stryker against repositories it does not own.

Impact for context: in a monorepo that centralises TargetFramework in per-slice Directory.Build.props — a common convention — every test project is affected, and the only remedy is to duplicate the literal into each .csproj and guard against it drifting out of step.

`

[dupdob]

thanks for raising this issue. There is a lot to process here, so I restate your problem to be sure I understand it:
Stryker fails when the test project target framework is defined only in a props file.
I think this is known issue with Buildalyzer, the library Stryker uses to perform project analysis. And I suspect this is a catch 22 situation where Buildalyzer needs to identify the target framework in order to select the correct SDK, but I may be wrong.

I will look into this anyway.

Some comments:

1. PR feat: Support solution configuration #3751 should fix the misleading 'no project found' error message, and may even fix the whole issue. It aims at improving (not fully addressing) most of your concerns here.
2. Same for the ambiguous report regarding the project analysis being both failed and successful. This is indeed due to the lack of identified target frameworks.
3. In any case, there is very little change that Stryker would be able to pinpoint the correct cause when project analysis fails
4. Did Stryker suggest using the --diag option and did this bring any extra information?

[PhilipThyregod]

One row is missing from the restatement, and it's the one that most supports your catch-22 reading: it also
fails when TargetFramework is in the test csproj, written as $(SliceTargetFramework) with the value
coming from Directory.Build.props. If the csproj is read before MSBuild evaluation in order to pick a
toolset, all four rows follow — literal works; absent isn't found; $(SliceTargetFramework) is found but
isn't a valid TFM; and a props file next to the project fails because imports aren't followed yet.

Re-verified all four on 4.16.0 / SDK 10.0.302, with a green dotnet build and
-getProperty:TargetFramework → net10.0 immediately before each run:

TargetFramework from	Stryker
literal in csproj	exit 0, scores
parent-directory Directory.Build.props	exit 1, No project found
Directory.Build.props beside the csproj	exit 1, No project found
$(SliceTargetFramework) in csproj	exit 1, No project found

On --diag, correcting myself: it is suggested — Use --diag option to have the analysis logs in the log file. prints right under the warning, and I did follow it. It yields 16 lines of Stryker's own trace with no
analyzer or MSBuild output in it, and the hint even reappears in the log of a run that already had --diag
enabled. Making it deliver would cover most of your point 3 — I'm not asking Stryker to name the cause, only
not to discard what the analyzer said.

[rouke-broersma]

and a props file next to the project fails because imports aren't followed yet

This statement is too absolute. Stryker itself uses Directory.Build.props and stryker-on-stryker works: https://github.com/stryker-mutator/stryker-net/blob/master/src/Directory.Build.props

This means the failure to resolve target framework is more specific than just 'Directory.Build.props is not used by buildalyzer'

3. refers to your following expectation:

Failing that, the error should name the missing/unresolved property instead of the generic No project found.

This is a chicken-and-egg. We resolve the target framework using Buildalyzer which does a design-time build of the project and captures msbuild output. Buildalyer analysis fails, which we log as project analysis failed, not valid projects found. If analysis fails, we can't properly determine why it failed, so we can't do much to improve this error message in Stryker. We simply don't have the information to determine that the property was unresolved.

[dupdob]

@PhilipThyregod : I am afraid my comments were not clear enough because it looks like my remarks failed to get through. This is not an issue as these were secondary.

I just add a look at Buildalyzer code to complete my understanding of what happens regarding framework determination:

1. Buildalayzer reads the project file to extract some key information before doing any analysis or processing
2. It uses the TargetFramework property to identify if the project is netcore or netframework, defaulting to netcore if unable to figure out
3. The property is read literally, without any form of variable resolution

So, if not TargetFramework is defined, Buildalyzer assumes this is a netcore project and plan to use the adequate environment, such as using dotnet build.

Stryker mainly (solely?) uses this property to identify if the project analysis was successful. Current Stryker version (pre PR #3751) have an annoying bug when this property is empty: they assume project analysis have been successful for all target framework of this project, even if some or all have failed. Consequently:

1. It does not perform any retry (such as running a nuget restore command)
2. It reports the analysis result incorrectly
3. but it correctly abort the run if it can execute it

In short:

• W/o an explicit framework stated in your csproj, Buildalyzer fails to perform the analysis for a yet unknown reason
• Stryker does not handle this failure gracefully due to a bug in a current version

This problem may be specific to net10, but we need more intelligence from Buildalyzer to better understand what is happening there