Bug 57930 - Building netstandard 2.0 project throws DllNotFoundException: hostfxr during msbuild
Summary: Building netstandard 2.0 project throws DllNotFoundException: hostfxr during ...
Status: RESOLVED FIXED
Alias: None
Product: Installers
Classification: Mono
Component: Linux packages (show other bugs)
Version: 5.2.0 (2017-04)
Hardware: PC Linux
: --- critical
Target Milestone: ---
Assignee: Jo Shields
URL:
Depends on:
Blocks:
 
Reported: 2017-07-04 12:59 UTC by Alexander Köplinger [MSFT]
Modified: 2017-07-06 16:00 UTC (History)
3 users (show)

See Also:
Tags: 2017-04
Is this bug a regression?: ---
Last known good build:


Attachments

Description Alexander Köplinger [MSFT] 2017-07-04 12:59:51 UTC
** NOTE: we can fix these issues independent of the OSX Mono MDK package, so this shouldn't have any effect on QA and the 15.3 dates. **

Building a simple .NET Standard project is broken in the msbuild we ship with Mono on Linux and Windows:

> $ cat Class1.cs
> using System;
> 
> namespace Test
> {
>     public class Class1
>     {
>     }
> }
> 
> $ cat test.csproj
> <Project Sdk="Microsoft.NET.Sdk">
> 
>   <PropertyGroup>
>     <TargetFrameworks>netstandard20</TargetFrameworks>
>   </PropertyGroup>
> 
> </Project>
> 
> $ msbuild
> 
> /test/test.csproj : error MSB4014: The build stopped unexpectedly because of an internal failure.
> /test/test.csproj : error MSB4014: System.DllNotFoundException: hostfxr
> /test/test.csproj : error MSB4014:   at (wrapper managed-to-native) Microsoft.DotNet.MSBuildSdkResolver.Interop:unix_hostfxr_resolve_sdk (string,string,System.Text.StringBuilder,int)
> /test/test.csproj : error MSB4014:   at Microsoft.DotNet.MSBuildSdkResolver.Interop.hostfxr_resolve_sdk (System.String exe_dir, System.String working_dir, System.Text.StringBuilder buffer, System.Int32 buffer_size) [0x00008] in <3faf79ce404840b3a95ccad4d02800ae>:0
> /test/test.csproj : error MSB4014:   at Microsoft.DotNet.MSBuildSdkResolver.Interop.hostfxr_resolve_sdk (System.String exe_dir, System.String working_dir) [0x00015] in <3faf79ce404840b3a95ccad4d02800ae>:0
> /test/test.csproj : error MSB4014:   at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.ResolveNetcoreSdkDirectory (Microsoft.Build.Framework.SdkResolverContext context) [0x0002a] in <3faf79ce404840b3a95ccad4d02800ae>:0
> /test/test.csproj : error MSB4014:   at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.Resolve (Microsoft.Build.Framework.SdkReference sdkReference, Microsoft.Build.Framework.SdkResolverContext context, Microsoft.Build.Framework.SdkResultFactory factory) [0x00020] in <3faf79ce404840b3a95ccad4d02800ae>:0
> /test/test.csproj : error MSB4014:   at Microsoft.Build.BackEnd.SdkResolution.GetSdkPath (Microsoft.Build.Framework.SdkReference sdk, Microsoft.Build.BackEnd.Logging.ILoggingService logger, Microsoft.Build.Framework.BuildEventContext buildEventContext, Microsoft.Build.Construction.ElementLocation sdkReferenceLocation, System.String solutionPath, System.String projectPath) [0x0007b] in <a41b30d6352847d9bf303b0f082a0cdc>:0

Jo and I looked at this on Friday and the reason is that we package libhostfxr.dylib for OSX but don't do the same for other OSes.

For Windows we can just package the relevant library from NuGet, but Linux is a bit more difficult.
The .NET Core SDK for example doesn't ship on ARM yet, but we do, so there's no package to take the library from.

Workarounds we looked at:
1. Remove the SDK resolver. Pro: fallback to the SDKs we ship kicks in. Cons: means users don't get desired behavior of picking SDKs in .NET Core where available. Also more difficult to only remove on e.g. ARM because msbuild is built only once for all archs.
2. Build libhostfxr.so ourselves

#2 looks promising, Jo is looking at it.
Comment 1 Jo Shields 2017-07-06 10:50:57 UTC
We're going for 1 and 2 at the same time.

The `msbuild` package now no longer contains the SDK resolver at all, and cleanly fails (or more accurately cleanly falls back to netstandard 1.3 from Mono)

I am now working on packaging a `msbuild-libhostfxr` package, which `msbuild` will try to install (but will happily ignore if unavailable), containing a self-built libhostfxr. `msbuild-libhostfxr` requires `msbuild-sdkresolver`, which has been split out from the old `msbuild` package.

The end result, once I'm finished, is `msbuild` will install a distro-specific libhostfxr - but if it can't do that, it'll skip it happily.
Comment 2 Alexander Köplinger [MSFT] 2017-07-06 10:56:51 UTC
Did you remove this from the msbuild install-mono.sh script to do the split up: https://github.com/mono/msbuild/blob/d15.3/install-mono-prefix.sh#L95-L97 ?

I'm wondering whether we should make that conditional to OSX so that users building the msbuild repo get a working product instead of a broken one: https://github.com/mono/msbuild/commit/62f5b50e9f23bfdac78d608a0192cb7985e603a7#commitcomment-22632340
Comment 3 Jo Shields 2017-07-06 10:59:51 UTC
(In reply to Alexander Köplinger from comment #2)
> Did you remove this from the msbuild install-mono.sh script to do the split
> up:
> https://github.com/mono/msbuild/blob/d15.3/install-mono-prefix.sh#L95-L97 ?
> 
> I'm wondering whether we should make that conditional to OSX so that users
> building the msbuild repo get a working product instead of a broken one:
> https://github.com/mono/msbuild/commit/
> 62f5b50e9f23bfdac78d608a0192cb7985e603a7#commitcomment-22632340

The standard behaviour with Debian package splitting is to install the world to a temporary prefix (debian/tmp) then pick and choose what goes where via debian/packagename.install files. See https://github.com/mono/linux-packaging-msbuild/blob/master/debian/rules#L15 and https://github.com/mono/linux-packaging-msbuild/blob/master/debian/msbuild-sdkresolver.install and https://github.com/mono/linux-packaging-msbuild/blob/master/debian/msbuild.install
Comment 4 Jo Shields 2017-07-06 16:00:46 UTC
Resolved in alpha-foo Debian/Ubuntu repos, needs fixing for RHEL 7. RHEL 6 will lack the feature.

Note You need to log in before you can comment on or make changes to this bug.