"Original project under test cannot be loaded" and "Unable to rollback mutation" when BuildOutputDir is changed relative to project dir

Hello, I’m very new to using Stryker, and I’m having trouble that is likely related to the way my project puts build outputs outside of the source directory.

First, the error (and the request for me to create an issue):

[15:55:18 WRN] Original project under test C:\_git\VFSforGit\src\GVFS\BuildOutput\GVFS.Common\bin\AnyCPU\Debug\netcoreapp2.1\GVFS.Common.dll could not be loaded.
Embedded Resources might be missing.
System.IO.FileNotFoundException: Could not find file 'C:\_git\VFSforGit\src\GVFS\BuildOutput\GVFS.Common\bin\AnyCPU\Debug\netcoreapp2.1\GVFS.Common.dll'.
File name: 'C:\_git\VFSforGit\src\GVFS\BuildOutput\GVFS.Common\bin\AnyCPU\Debug\netcoreapp2.1\GVFS.Common.dll'
   at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
   at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at Mono.Cecil.ModuleDefinition.ReadModule(String fileName, ReaderParameters parameters)
   at Stryker.Core.Initialisation.EmbeddedResourcesGenerator.LoadModule(String assemblyPath, ILogger logger) in C:\_git\stryker-net\src\Stryker.Core\Stryker.Core\Initialisation\EmbeddedResourcesGenerator.cs:line 42
[15:55:19 ERR] Unable to rollback mutation for node FileAttributes with error: Ambiguity between 'FileProperties.FileAttributes' and 'FileProperties.FileAttributes' (at C:\_git\VFSforGit\src\GVFS\GVFS.Common\FileSystem\FileProperties.cs, line: 7, col: 80).
[15:55:19 ERR] This should not happen, please report this as an issue on github with the previous error message.

Note that we use build variables to specify that SolutionDir would be C:\_git\VFSforGit\src and the build outputs should go in C:\_git\VFSforGit\BuildOutput, but here a couple of levels are skipped. This is likely due to the following lines in our .csproj settings:

    <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..</SolutionDir>
    <BuildOutputDir>$(SolutionDir)\..\BuildOutput</BuildOutputDir>
    <PackagesDir>$(SolutionDir)\..\packages</PackagesDir>

This should make the SolutionDir be two levels above the project directory, and the build outputs go in ..\BuildOutputDir relative to that (which works during dotnet build). It appears that when Stryker mutates the code, something is going awry and causes some duplication of code.

My guess is that the mutated code is being placed in a deeper directory than normal, and hence the build outputs are being placed deeper in the source tree than usual. Alternatively, we are forcing the mutated outputs into the same spot as the non-mutated code and Stryker is trying to replace the mutation with the original binary. However, I’m not exactly sure how to resolve this issue.

I’d love to use Stryker to improve our test coverage, so I appreciate any pointers you can give.

[rouke-broersma]

Hey @derrickstolee ,

We have identified the issues with compiling your project, and it turned out to be a problem in our logic of loading shared projects which resulted in loading the complete GVFS codebase instead only the project under test. We have fixed this, and have identified another issue in the process. We do not version the assembly we write to disk, which fails 4 of the unit tests in the project because they rely on an assembly version. We are going to try and copy the original assembly version number when compiling our mutated assembly.

We have also identified a problem with finding the solution directory when no solution file is passed to stryker, this resulted in the build output folder not being correctly identified. For now I suggest you pass the GVFS sln file to stryker so the solution dir and build output dir are correctly found.

[derrickstolee]

Thanks for the ping @Mobrockers and for the detailed parameters. I ran the same thing and got a meaningful report! Of course, we need to do better with our unit tests, as very few mutations were killed.

Thanks so much for your help here!