Add a property with path of host of msbuild

Add a property with full path of host of msbuild

I can currently run msbuild with

• msbuild.exe (net40)
• dotnet msbuild.dll (netcore)
• mono msbuild.exe (too i think, for net40)

It’s useful in target file to know who is invoking msbuild, because maybe i need to run some commands in my target files, and i want to use same host.

For example i want to run a clitool or another command in a target file

<Target Name="MyTarget">
    <Exec Command='dotnet mytool arg1 arg2' />
</Target>

But that will run dotnet in PATH (global.json cannot always be used, because i can overriden in PATH, like in CI server)

set PATH=/path/to/v1/dotnet
/path/to/v2/dotnet msbuild /t:MyTarget

that will run mytool with v1 dotnet, and i dont know how to be sure is executed with v2 dotnet

Same for mono.

If a $(DotnetHost) exists, it’s possibile to do $(DotnetHost) mycmd.dll or $(DotnetHost) mycmd.exe (netcore vs net40) and that will run

• mycmd.exe on win, because $(DotnetHost) is ‘’
• /path/to/dotnet.exe mycmd.dll on .net core win
• /path/to/dotnet mycmd.dll on .net core unix/mac
• /path/to/mono mycmd.exe on mono

I think that property should be added from msbuild, not sdk, because i can use msbuild without sdk (for simple script automation)

that also resolve workaround like (from dotnet run target file in dotnet/sdk )

    <PropertyGroup>
      <_DotNetHostExecutableName>dotnet</_DotNetHostExecutableName>
      <_DotNetHostExecutableName Condition="$(RuntimeIdentifier.StartsWith('win'))">$(_DotNetHostExecutableName).exe</_DotNetHostExecutableName>
    </PropertyGroup>

There is $(MSBuildSDKsPath) but is a subdirectory inside sdk, and i dont know if i can be sure layout will be always the same, to use relative path. And anyway doesnt fix mono or msbuild.exe

related to https://github.com/Microsoft/msbuild/issues/720 too i think, roslyn csc workaround embeddeing a .cmd/.sh inside sdk (who resolve dotnet using relative path), but that cannot be done by others.

Atm in f# (i need to run dotnet fsc.dll, with full path), i am using MSBuildExtensionsPath but i know is not future proof/hack

<_FscTask_FscToolExe>dotnet.exe</_FscTask_FscToolExe>
<_FscTask_FscToolPath>$(MSBuildExtensionsPath)/../..</_FscTask_FscToolPath>

[enricosada]

Also, as i said before, it’s not a problem specific to fsc (that’s just an example), it’s for normal targets who want to run dotnet from msbuild (build orchestration, scripts, etc). But for sure is really high in my priority list for finalize F#, because can create bug

QUESTION: If i want to run a dotnet something inside my target file? i cannot do <Exec Command="dotnet new -t lib" /> because i cannot trust PATH

• maybe a specific version of dotnet is executed with full path /path/to/dotnet msbuild /t:MyTarget, happen a lot with installations in CI (download -> unzip)
• maybe global.json is used

So ihmo is not about sdk, cli at all. It’s about msbuild. before there was only one host, now there are more, so i need to know with one. I know easy is ignore it, but mostly because the sdk/cli bundle everything, so you dont see the issue often.

@piotrpMSFT @livarcocc - how do you guys imagine F# compiler should work when running in the CLI?

I add my 5c.

My working solution for f# (work is done, i’ll send a pr really soon to update templates) is to:

• publish the fsc compiler as normal framework dependent netcoreapp console app (fsc.dll)
• put it inside nuget package FSharp.Compiler.Tools (who already exists/used for f#, but contains net40 only atm, will be updated with netcoreapp too)
• That FSharp.Compiler.Tools package is referenced by Sdk package currently used for F# FSharp.NET.Sdk
• I can know the full fsc.dll path inside the package because in the FSharp.Compiler.Tools package i define a property FscPath, auto-imported by props file.
• in the target CoreCompile inside FSharp.NET.Sdk i just <Exec Command='dotnet "$(FscPath)" --fsc-args' />

Working example in this package, but is not final name, after feedback/todo from https://github.com/Microsoft/visualfsharp/pull/2250

It works really well, minimal package size (FDD) and xplat. no special invoker (RunCsc.cmd/.sh, who hardcode dotnet path btw, using relative position, because is important know the good path). Package contains both net40 and netcoreapp1.0, so i can run net40 when msbuild.exe or netcoreapp when is dotnet msbuild if i want (not atm). No hack, just using current msbuild extensibility (auto-import of props).

Please do not embeed f# it in CLI, no special cases. is not needed.

Current packaing for f# is better than c# one ihmo:

• I can replace the f# compiler package just changing the package version inside fsproj.
• with c# you are stuck to CscPath property (that works too for f# obv, with FscPath), but a package is better, we are doing package as first class right? not local paths to gac/special folder anymore:
  • for versioning
  • i can PIN the specific fsc package version, or use experiemental built version (no hack, just change a <PackageReference Include="Microsoft.FSharp.Compiler.Sdk.netcore" Version="myversion" /> and dev feed maybe
  • easier to use/change for users (no download, local file system FscPath)
  • contains fsharp.build.dll with Fsc msbuild task, so always aligned to fsc
  • each fsproj can choose what fsc use, default latest stable obv
  • default fsc package is referenced in fsharp.net.sdk package, so is not needed inside fsproj

[rainersigwald]

Team triage: We’ve made it this long without this, so we don’t plan to do it. Hosts are changing quite a bit with apphosts now, too.