Skip to content
This repository has been archived by the owner on Jan 8, 2019. It is now read-only.

DotNetHost path when compiling with Mono's MSBuild #75

Closed
mrward opened this issue Feb 17, 2017 · 6 comments · Fixed by #86
Closed

DotNetHost path when compiling with Mono's MSBuild #75

mrward opened this issue Feb 17, 2017 · 6 comments · Fixed by #86

Comments

@mrward
Copy link

mrward commented Feb 17, 2017

Visual Studio for Mac uses MSBuild that ships with Mono 4.8.0 to compile .NET Core projects. With F# projects this currently fails since the FSharp.NET.Core.Sdk.targets assume that the dotnet host executable ships with MSBuild which is not the case for Mono.

Building with Mono:

  Set Property: _DotNetHostExecutableName=dotnet
  Set Property: _DotNetHostExecutableDirectory=/Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/xbuild/../..
  Set Property: _DotNetHostExecutablePath=/Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/xbuild/../../dotnet
  Set Property: _FscTask_FscToolExe=dotnet
  Set Property: _FscTask_FscToolPath=/Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/xbuild/../..
  Set Property: _FscTask_DotnetFscCompilerPath= "~/.nuget/packages/fsharp.compiler.tools/4.1.0/build/netcoreapp1.0/fsc.dll"

Build FAILED.

~/.nuget/packages/fsharp.net.sdk/1.0.0/build/FSharp.NET.Core.Sdk.targets(122,9): error MSB6004: The specified task executable location "/Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/xbuild/../../dotnet" is invalid.

Building with dotnet:

  Set Property: _DotNetHostExecutableName=dotnet
  Set Property: _DotNetHostExecutableDirectory=/usr/local/share/dotnet/sdk/1.0.0-rc4-004771/../..
  Set Property: _DotNetHostExecutablePath=/usr/local/share/dotnet/sdk/1.0.0-rc4-004771/../../dotnet
  Set Property: _FscTask_FscToolExe=dotnet
  Set Property: _FscTask_FscToolPath=/usr/local/share/dotnet/sdk/1.0.0-rc4-004771/../..
  Set Property: _FscTask_DotnetFscCompilerPath= "~/.nuget/packages/fsharp.compiler.tools/4.1.0/build/

FSharp.NET.Core.Sdk.targets:

<_DotNetHostExecutableName>dotnet</_DotNetHostExecutableName>
<_DotNetHostExecutableName Condition=" '$(OS)' == 'Windows_NT' ">$(_DotNetHostExecutableName).exe</_DotNetHostExecutableName>
<_DotNetHostExecutableDirectory>$(MSBuildExtensionsPath)/../..</_DotNetHostExecutableDirectory>
<_DotNetHostExecutablePath>$(_DotNetHostExecutableDirectory)/$(_DotNetHostExecutableName)</_DotNetHostExecutablePath>

Visual Studio for Mac can compile F# .NET Core projects if the MSBuildExtensionsPath property is set to point to the correct .NET Core Sdk folder. However I am wondering if this the best way to solve this. Would it be possible to configure _DotNetHostExecutableDirectory property through another MSBuild property other than MSBuildExtensionsPath? So the FSharp.NET.Core.Sdk.targets would have something like:

<_DotNetHostExecutableDirectory Condition="$(_DotNetHostExecutableDirectory ) == '' ">$(MSBuildExtensionsPath)/../..</_DotNetHostExecutableDirectory>

Or perhaps better use the MSBuildSDKsPath property which is used with the Microsoft.NET.Sdk MSBuild targets:

<_DotNetHostExecutableDirectory>$(MSBuildSDKsPath)/../../..</_DotNetHostExecutableDirectory>

The MSBuildSDKsPath points at the Sdks directory:
/usr/local/share/dotnet/sdk/1.0.0-rc4-004771/Sdks/

@enricosada
Copy link
Contributor

Hi @mrward . Yes atm i suppose build is with dotnet core sdk run by dotnet, not mono based or windows .net framework msbuild.exe .

We can fix it as you said, using $(MSBuildSDKsPath).

Should be safe, because now in rc4 RunCsc.sh (who run csc) is inside Sdks, and hardcoded relative path /../../../dotnet to find dotnet (same for windows RunCsc.bat file).
Before (preview4, maybe rc3) was near msbuild.exe. that's why i used $(MSBuildExtensionsPath), to use same relative path as csc was using (do what csc does is always good for maintanability).

@enricosada
Copy link
Contributor

@mrward as a related note, i asked msbuild team to provide a property to know who is invoking msbuild (ref dotnet/msbuild#1669). so will be possibile to know exact dotnet location. or know if it's mono or win.
That's useful, not only to know dotnet real path, but because i can use that info to invoke tools, like choose dotnet based or mono based fsc for example (FSharp.Compiler.Tools packages contains both)

@enricosada
Copy link
Contributor

@eerhardt @rainersigwald @jeffkl @nguerrera @dsplaisted @piotrpMSFT any idea if there is a property with path of dotnet host?

Or if doing like proposed by @mrward using relative to $(MSBuildSDKsPath) is ok?

enricosada added a commit to enricosada/netcorecli-fsc that referenced this issue Feb 23, 2017
enricosada added a commit that referenced this issue Feb 23, 2017
@rainersigwald
Copy link
Member

No, no property like that currently. Since you have a Mono fsc, maybe you could switch on '$(MSBuildRuntimeType)' == 'Mono'?

I don't like finding dotnet by relative path from MSBuildSdksPath--it will probably work fine for a while, but I would expect it to be fragile (we have very little reason to keep the folder structure the same, and it's meaningless after we get Sdk acquisition working.

(sorry, I typed this up but never hit "comment" . . . hopefully better late than never)

@enricosada
Copy link
Contributor

Also if i can use $(MSBuildRuntimeType), i dont know where dotnet is.
I need to locate dotnet because i use that to run f# compiler, as dotnet /path/to/fsc.dll

Well for sdk 1.0 the MSBuildSdksPath should do (works for mono and netcore sdk, dunno VS).

I'll open an issue in sdk to discuss future for sdk 2.0
Is an issue for third party packages long term, who want to run tools (and best tool are framework dependent app) embedded in packages.

Thx a lot @rainersigwald for feedback

@enricosada
Copy link
Contributor

@mrward the FSharp.NET.Sdk v1.0.1 is published on nuget and contains this fix.

Please update me if there are other issue with mono/vs on mac, or things work. I'll try to add soon mono CI to this repo with #78

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants