Warn the user when it is running in an unsupported environment/configuration

[xandervedder]

Is your feature request related to a problem? Please describe.
We were trying to run Stryker.NET on a .NET Framework project on an Azure Agent, but it crashed after around 30 seconds. Eventually we found out that the agent was using Linux. Obviously, in most scenarios that does not work, but it took us a while to figure out what exactly the problem was.

Describe the solution you'd like
I would like to see Stryker.NET warn us when it is running in an unsupported environment/configuration (Linux and .NET Framework in this case).

Maybe something along the lines of:
[xx:xx:xx WRN] Stryker detected an unsupported running configuration. Stryker might not work as expected.

Additional context
This is the error we came across:

[05:57:18 ERR] An error occurred during the mutation test run 
System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'where.exe' with working directory '/home/vsts/work/1/s'. No such file or directory
   at Stryker.Core.Initialisation.InputFileResolver.AnalyzeAllNeededProjects(List`1 projectList, StrykerOptions options, IAnalyzerManager manager, ScanMode mode)
   at Stryker.Core.Initialisation.InputFileResolver.AnalyzeAndIdentifyProjects(List`1 projectList, StrykerOptions options, IAnalyzerManager manager, ScanMode mode)
   at Stryker.Core.Initialisation.InputFileResolver.ResolveSourceProjectInfos(StrykerOptions options)
   at Stryker.Core.Initialisation.InitialisationProcess.GetMutableProjectsInfo(StrykerOptions options)
   at Stryker.Core.Initialisation.ProjectOrchestrator.MutateProjects(StrykerOptions options, IReporter reporters, ITestRunner runner)
   at Stryker.Core.StrykerRunner.RunMutationTest(IStrykerInputs inputs, ILoggerFactory loggerFactory, IProjectOrchestrator projectOrchestrator)

[dupdob]

Stryker is supposed to work on Linux, and it is tested on Linux (and macOs for that matter) during integration testing.
So this is a bug

[rouke-broersma]

@dupdob this is full framework on linux, which is not really supported. We assume we can run vswhere.exe when we are dealing with full framework, but on most linux systems vswhere.exe (and msbuild for that matter) will not be available. currently this crashes with a Win232xception which is not very friendly.

We might at some point be able to detect this scenario and build using mono?

[dupdob]

ah, thanks :-)
it is still a bug thought: it should fail properly with a 'project analysis failed' or 'build failed' message, not a crash

[rouke-broersma]

I would class this more as user error. Dotnet framework does not properly build on linux (unless you use mono, but we don't claim to support mono). Hinting to the user that they are doing something unsupported is a nice to have, but really this is PEBCAK. Especially since @xandervedder is a coworker 🤡

[xandervedder]

Yes this is definitely a user error 😄, but it might save some time for other users if we warn them about it.

[bhargava-raju]

I want to work this bug, could you assign it to me

[dupdob]

I want to work this bug, could you assign it to me

Take the time to reproduce it first; there have several changes in the initialization phase (especially a lower reliance on 'where.exe'), so behavior may be better and has definitely changed