Add a property with path of host of msbuild

[enricosada]

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 #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>

[rainersigwald]

We went around and around on this in #720 and decided to do the easy thing (nothing) for now.

@eerhardt It looks like you might have changed your mind and now be in favor of an MSBuild feature to get the host?

[eerhardt]

@eerhardt It looks like you might have changed your mind and now be in favor of an MSBuild feature to get the host?

?? I'm not sure what I've changed my mind "from" or "to". 😉

It would seem to me, for this specific issue, to give F# the same level of specialty as we do for C#. We are already bundling the F# SDK into the CLI. It would make sense to add the same functionality for F# as we do for C#:

https://github.com/dotnet/cli/blob/rel/1.0.0/src/dotnet/commands/dotnet-msbuild/MSBuildForwardingApp.cs#L29
https://github.com/dotnet/cli/blob/rel/1.0.0/src/dotnet/commands/dotnet-msbuild/MSBuildForwardingApp.cs#L109-L113

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

Either that, or we need to generalize this so C# doesn't need to be special cased in the CLI.

[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 dotnet/fsharp#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

[enricosada]

@rainersigwald so no possibility to have it in .net core sdk 1.0 right?

[rainersigwald]

No, sorry.

[weshaggard]

FWIW I agree we need something like this as well. There are various things we need to be able to run on the same host as msbuild so it runs in the same context as msbuild.

[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.