The MSBUILD_EXE_PATH environment variable is set for CLI Tools

[matthid]

I noticed a small difference when running dotnet-tools via dotnet <toolname> (referenced via DotNetCliToolReference).

When you run your tool as SCD or FDD the environment variable MSBUILD_EXE_PATH is not set while for dotnet <tool> it is set to something ('MSBUILD_EXE_PATH' -> 'C:\Program Files\dotnet\sdk\2.1.4\MSBuild.dll' on windows for example).

If you use a dotnet-cli tool to call an external msbuild process this can lead to some strange errors (see fsprojects/FAKE#1776 for the issues and the analysis).

So my question now is: Is this difference by design or by mistake? Should we fix it here or add some detection into the dotnet-cli tool?

dotnet --info output:

.NET Command Line Tools (2.1.4)
Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190
Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 RID:         ubuntu.14.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.4/
Microsoft .NET Core Shared Framework Host
  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

and

.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.4\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

[livarcocc]

This is by design. We need to fix this in your own tool.

When you invoke your FDD or SCD app, the CLI is not in play. The runtime is really the only thing involved and you may or may not have a version of MSBuild available. If your application depends on MSBuild, it is your apps responsibility to find it and configure it. Also think that not all apps will require MSBuild. I would argue that only a minority of them will.

Hope this helps.

[matthid]

Ok thanks will add the required fix. Is there a reasoning for setting this variable in this particular situation?

[matthid]

Ok it seems the reason is dotnet/msbuild#1097.