Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
** 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">
> $ 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.
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.
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
(In reply to Alexander Köplinger from comment #2)
> Did you remove this from the msbuild install-mono.sh script to do the split
> 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:
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
Resolved in alpha-foo Debian/Ubuntu repos, needs fixing for RHEL 7. RHEL 6 will lack the feature.