Using msbuild over xbuild causes issues ( at least on Mono 4.8.x)

[dsyme]

cc @baronfel

Recent FAKE (> 4.53.0?) has caused a regression on Linux/macOS with Mono 4.8 and Mono latest (currently 4.8.1). It invokes MSBuild instead of XBuild on these platforms (this PR).

That's fine, but I believe MSBuild on Unix/Mono has problems, at least before Mono 5.0.0 (yet to be released). For example, when compiling FSharp.Compiler.Service with (latest FAKE and FSharp.,Compiler.Tools](https://travis-ci.org/fsharp/FSharp.Compiler.Service/jobs/227043065) using this:

  /Library/Frameworks/Mono.framework/Versions/Current/Commands/msbuild  /Users/travis/build/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.sln /t:Build    /p:RestorePackages="False" /p:Configuration="Release" /p:TargetFrameworkVersion="v4.5" /logger:Fake.MsBuildLogger+ErrorLogger,"/Users/travis/build/fsharp/FSharp.Compiler.Service/packages/FAKE/tools/FakeLib.dll"

I get

/Users/travis/build/fsharp/FSharp.Compiler.Service/packages/FSharp.Compiler.Tools/tools/Microsoft.FSharp.Targets(125,13): 
error MSB4131: The "ResourceFilesWithManifestResourceNames" parameter is not supported by 
the "CreateFSharpManifestResourceName" task. Verify the parameter exists on the task, and it 
is a gettable public instance property. 
[/Users/travis/build/fsharp/FSharp.Compiler.Service/src/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj]

This seems to be an MSBuild on Unix and Mono issue.

I suspect we should be avoiding defaulting to MSBuild on Unix, at least on Mono 4.8.x and before. I've yet to validate if this issue goes away on Mono 5.0.0.

Repro steps

Consider this PR.

• this commit fails to build. It uses latest FAKE and invokes msbuild on Unix

• I'm in the process of validating that this commit succeeds. It uses FAKE 4.53.0 instead of FAKE 4.60.0 and invokes xbuild on Unix

Known workarounds

Use FAKE 4.53.0 or before (I'm in the process of validating this)
Perhaps use Mono 5.0.0 (?)

Related information

• Unix, Mono 4.8.*

[dsyme]

@nosami Have you seen anything like this? Thanks

[baronfel]

You can try your test setting the MSBuild environment variable to the path to xbuild on that system to validate. One of the things I did in that PR was unify the resolution logic across OSs to look for that variable.

[nosami]

@dsyme: It doesn't surprise me. There were many issues with msbuild on mono 4.8.0 that have since been fixed.

The FCS commit that you linked to builds fine using msbuild on mono 5.0.0.89

[matthid]

@baronfel Maybe we should default to xbuild for <mono5 (ie change the order)?
And additionally we should allow setting the Environment variable to the msbuid or xbuild string and then try to find the tool in path.

[baronfel]

Those both seem like fine resolutions. Do we already have a good way of determining the mono version in FAKE? I know we know if we're running in mono at all, but not sure about the version.

[matthid]

@baronfel https:/fsharp/FAKE/blob/master/src/app/FakeLib/EnvironmentHelper.fs#L151 was added because of the Mono5 runtime crash... Usage is https:/fsharp/FAKE/blob/master/src/app/FakeLib/FSIHelper.fs#L491
Now thinking about it the warning handling should probably move to the monoVersion definition...

[matthid]

@baronfel are you on it?

[baronfel]

ok, starting to look at this now. for mono <= 4.8 we'll use xbuild over msbuild, while still allowing to user to specify the env variable to override the path

[baronfel]

@dsyme @matthid you guys want to look at #1540 to see if it behaves how you'd like?