Passing build variables to MSBuild.exe

I was referred to stryker by a co-worker who is really excited about mutation testing in general. After reading the documentation I decided to get it a try. My project is using the .Net Framework, not .Net Core so I expected some hiccups.

After installing the global tool and specifing the sln file, msbuild finally ran but failed. The reason is because a targets file isn’t in the expected location. How can this be since I can run it in Visual Studio without a problem? Turns out, Visual Studio modifies some of the build variables so keep certain consistencies.

In my case, I’ve installed the DacFx nuget package and it adds a Microsoft.Data.Tools.Schema.SqlTasks.targets files that allows me to build a SQL Server Data Tools project. This file is placed by the nuget install in the C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\SSDT because the MSBuildExtensionsPath was modified to be C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild. Normally the path is C:\Program Files (x86)\MSBuild.

If there were a way to set the property values from either the command line or the configuration file the issue could be resolved with very little change to the stryker code itself. While I’m approaching this from a .Net Framework perspective, I’ve used the dontnet cli as well and am aware that it can use the MSBuild properties as well. It seems this would be a powerful addition that would allow the developers to harness more of the build process without having to build in specific support for something.

*** Notes ***

This feature should probably be implemented as a config file only option.

[richardwerkman]

Sorry the link was mainly meant to show how to override the variable, not the flaky msbuild behaviour.

I didn’t understand it was so important that the variable stays flexible. Now I see why you’d want to be able to pass the variable at runtime. However I’m not so fond of passing individual msbuild parameters. Maybe we could create an option to pass extra parameters as a full string. It could look like:

dotnet stryker --msbuild-params "/p:MSBuildExtensionPath='C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild' /p:Configuration=Debug"

And we would always place it behind the solution path here: https://github.com/stryker-mutator/stryker-net/blob/4530ff5c251cf7b139eb4ff0c58fd60065a9bb22/src/Stryker.Core/Stryker.Core/Initialisation/InitialBuildProcess.cs#L38

If the option is optional an empty string would be added by default so there are no extra parameters passed to msbuild. If the option has a value it would be passed to msbuild like:

msbuild.exe ../mysolutionfile.sln /p:MSBuildExtensionPath='C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild' /p:Configuration=Debug

I think this would be a future proof solution without much effort 👍

Of course we should handle errors better for when wrong parameters are passed through stryker to msbuild.

[rouke-broersma]

@bcollamore Buildalyzer does not use MSBuild API’s per se. What it does is call MSBuild.exe with a specific set of instructions to register eventhandlers for specific events msbuild outputs. From these events buildalyzer can build up the complete project structure as msbuild reads it as far as I understand.

This is necessary because during building the required msbuild targets are called in to find all project level information such as required assemblies. I would love an example of how we can do this without buildalyzer, but to me it sounds like we would just be remaking buildalyzer and/or msbuild at that point, and would be hitting the same issues buildalyzer is hitting when clean is removed.