EnableWindowsTargeting must be set for some projects to build successfully on linux #2938
Comments
|
hi |
|
Thx for your reply. Yes, the .NET SDK is installed on this machine. If that wouldn't be the case, it should already fail on the very first run (i. e. |
|
I am not sure single project would fail: they could pass if they are light enough. |
|
That was a good guess, man 💪🏻 running When changing this to |
|
Thanks, but that's not a guess, it was logged. As of today, there is no way to pass MsBuild properties across Stryker, but you can add the properties in windows targeting projects' csproj files: <PropertyGroup>
<EnableWindowsTargeting>true</EnableWindowsTargeting>
</PropertyGroup>I think it should do the trick |
|
You can probably set this with a condition |
|
Thx, I will give it a try and report back |
|
I tried it yesterday multiple times with enabling However, what I don't understand is the following: I'm using a Stryker config file like this: {
"stryker-config": {
"test-case-filter": "Category=Unit",
"project": "Company.ProjectD.Features",
"test-projects": ["tests/Company.ProjectD.Tests.Component/Company.ProjectD.Tests.Component.csproj"]
}
}According to the docs, I'm not using Stryker's solution file context, but yet the solution is built by Stryker. When only running |
|
When you run from a folder containing a solution file, you run in solution mode. Since you're specifying a relative path to your test project and are setting a project name, it does indeed look like you're running in solution mode. The pipeline also makes it seem like you're running in solution mode since you seem to set the working directory to the repository root: |
rouke-broersma
changed the title
|
So I have to explicitly |
The primary way stryker determines the execution mode is based on the information available (do we have a solution file, do we have a project file, do we have a test project file). This information can be provided using config but stryker also tries to auto-detect this based on the current working directory. If the current working directory contains a solution file, we automatically run in solution mode. If the current working directory contains a project file we try to determine whether or not this is a test project. If it is a test project, we run in test project mode. Otherwise we run in source project mode. If no solution file or project file is found in the working directory we base the mode to use solely on the configuration provided by the user. |
Purpose Improve the project discovery and analysis phase and improve the design of associated classes. Fixes relevant issues along the way Changes Project discovery and Solution mode (main changes) Alignement The general processing is now identical for both modes. The difference is in how individual projects are discovered: in solution mode, Stryker works with every project of the solution in project discovery mode, Stryker recursively discovers project, starting with the provide test project(s) and add any project dependencies Note that other strategies are easy to implement, such as full recursive discovery: testing all projects are referenced (incl. transitively) by a set of test projects. Project Analysis Configuration: the user can now specify the desired (project/solution configuration (e.g Release) instead of Stryker peeking the default one. Multi-target: Stryker respects exact inter project dependencies, including target framework version and target platform Filtering: SourceProject option works for solution mode too Platform: Stryker uses the target platform settings (if specified) when running tests. Resiliency: Stryker retries project analysis when Buildalyzer failed to detect dependency. Stryker considers an analysis as failed if it did not report any source files or any dependencies, disregarding the BuildAlyzer status. MsBuild may report a build as failed if some secondary target fails, on the other hand, BuildAlyzer will report a success while it failed to capture any dependencies. Logging: Stryker provides MsBuild log for both project and solution mode (with -dev—mode modifier) as well as analysis result details. Content files: Stryker perform a post build scan of dependencies to identify content files from nugget packages such as ‘MimeTypes’. This is a workaround until BuildAlyzer is able to detect them CLI -configuration : new option that allows to specify which configuration to build (Debug, Release…). This should be a solution configuration in ‘solution’ mode. Misc compilation phase: compilation stops (and fails) immediately if Stryker is unable to identify any (new) mutation causing errors. Previously it recompiled the same code until the max attempts is reached initial build: log first build attempt when it fails (Trace level), use dotnet msbuild instead of msbuild.exe on non windows platform initial build: ensure quotes are applied for space containing path in every situation Main changes in design Merged ProjectFileReader class with InputFileSolver as responsibilities were blurry between them. Added several tests for not yet covered cases Github issues fix #2930, fix #2748, fix #2693, fix #2587 related: #2886, #2393, #2077, #2938
Describe the bug
We're running Stryker every night on Jenkins for several of our projects. After a couple of successful runs, Stryker crashes with
System.IO.FileNotFoundException: MsBuild.exe could not be located.Logs
Uncollapse me for logs
Expected behavior
As it does not fail when running the projects individually, it must not fail in this case either.
Desktop (please complete the following information):
4.0.5Additional context
Here's the relevant section from the
Jenkinsfile:The text was updated successfully, but these errors were encountered: