Sqlproj file stops stryker running

[Siphonophora]

Describe the bug I have a solution which includes a bunch of csproj, and one sqlproj. The existence of the sqlproj breaks the initial build step, and therefore stryker as a whole.

Note, stryker runs just fine with the config below if I remove the sqlproj from this solution.

{
    "stryker-config": {
        "solution": "MySoftware.sln",
        "project": "MySoftware.Common.csproj",
        "test-projects": [
            "./test/MySoftware.UnitTests/MySoftware.UnitTests.csproj"
        ],
        "ignore-methods": [
            "Console.Write*",  // Ignores all methods starting with Write in the class Console
            "*Exception.ctor", // Ignores all exception constructors
            "Log.*",           // Ignores all logging
            "logger.*",           // Ignores all logging            
            "ForContext",      // Ignores all logging config
            "ConfigureAwait"   // We don't test async in a way this would matter.
        ]
    }
}

Logs

Initial build of targeted project failed. Please make sure the targeted project is buildable. You can reproduce this error yourself using: "dotnet build
"C:\redacted\src""

Expected behavior I expect that specifying the project and test projects would lead to narrower builds and not just a dotnet build of the whole solution. And that in turn would mean the sqlproj didn't break stryker.

Or maybe specifying the msbuild path should be obeyed. I tried to get this to run using msbuild path, but it still fell back on the dotnet build command. But I like this option a lot less.

Desktop (please complete the following information):

• OS: Windows
• Type of project .Net 7
• Stryker Version 3.10.0

[Siphonophora]

Oh, and it does run fine if I delete the .sln file before running stryker. That isn't out of the question in a CICD context, but not ideal

[rouke-broersma]

The solution, project and test project config are all optional. You can run Stryker from the test project directory and you wouldn't need to specify any of them. We would also not try to build the solution if you run from the test project. See: https://stryker-mutator.io/docs/stryker-net/operating-modes/#test-project-context

The msbuild path is only relevant for dotnet framework projects. Dotnet build is always used for dotnet core.

[dupdob]

@rouke-broersma: do we have a strong reason to use dotnet build when in solution mode (instead of msbuid)?

[rouke-broersma]

@rouke-broersma: do we have a strong reason to use dotnet build when in solution mode (instead of msbuid)?

No it just grew that way because the first version only had support for dotnet core and when we added support for dotnet framework we needed the sln and msbuild.

Tho I'm not sure how using msbuild in this case would solve the problem they're having. And I think buildalyzer might also try to use dotnet cli instead of msbuild.

[dupdob]

thanks. My understanding is that BuildAlyzer relies on MsBuild output (and not dotnet build), but I may be wrong. Anyway, will try to reproduce, see if the change brings any benefit and report results

[rouke-broersma]

thanks. My understanding is that BuildAlyzer relies on MsBuild output (and not dotnet build), but I may be wrong. Anyway, will try to reproduce, see if the change brings any benefit and report results

buildalyzer uses dotnet cli or msbuild depending on build context. dotnet cli also implements msbuild but slightly different. Buildalyzer. See: https://github.com/daveaglick/Buildalyzer/blob/main/src/Buildalyzer/Environment/DotnetPathResolver.cs

[Siphonophora]

The solution, project and test project config are all optional. You can run Stryker from the test project directory and you wouldn't need to specify any of them. We would also not try to build the solution if you run from the test project. See: https://stryker-mutator.io/docs/stryker-net/operating-modes/#test-project-context

Thanks. Stryker did run as soon as was running it from a different directory than the solution (because it ignores the solution in that case). That didn't click for me looking at the docs before. This is an approach I can totally live with.