MSBuildLocator.QueryVisualStudioInstances Fails on Mac and Linux from Version 1.5.3 #210
Description
Starting from version 1.5.3, the MSBuildLocator.QueryVisualStudioInstances method fails to execute in Mac and Linux environments. The error message is as follows:
One or more errors occurred. (Unable to load shared library 'hostfxr' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libhostfxr, 1): image not found)
Inner exception: Unable to load shared library 'hostfxr' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libhostfxr, 1): image not found
System.AggregateException: One or more errors occurred. (Unable to load shared library 'hostfxr' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libhostfxr, 1): image not found)
---> System.DllNotFoundException: Unable to load shared library 'hostfxr' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libhostfxr, 1): image not found
at Microsoft.Build.Locator.NativeMethods.hostfxr_resolve_sdk2(String exe_dir, String working_dir, hostfxr_resolve_sdk2_flags_t flags, hostfxr_resolve_sdk2_result_fn result)
at Microsoft.Build.Locator.DotNetSdkLocationHelper.GetDotNetBasePaths(String workingDirectory)+MoveNext()
at Microsoft.Build.Locator.DotNetSdkLocationHelper.GetInstances(String workingDirectory)+MoveNext()
at Microsoft.Build.Locator.MSBuildLocator.GetInstances(VisualStudioInstanceQueryOptions options)+MoveNext()
It's worth noting that the QueryInstancesTests.DefaultInstanceTest unit test fails with the same issue on my mac.
The underlying cause of this issue is the DllImport("hostfxr"...) fails. It cannot find the hostfxr library without additional information about its location. There are similar issues previously reported on dotnet previews, such as dotnet/runtime#54965. The dotnet team resolved these issues by:
- Setting a HOSTFXR_PATH environment variable in the muxer, which identifies the hostfxr library's location (https://github.com/dotnet/dotnet/blob/028fdc758497de68844aea024cc2c6a0c868dc50/src/runtime/src/native/corehost/fxr/fx_muxer.cpp#L483).
- Adding a custom library resolver that uses the HOSTFXR_PATH environment variable to resolve the hostfxr library (https://github.com/dotnet/sdk/blob/4ea3e8304c21022bbea72a29154b7602af4f9239/src/Resolvers/Microsoft.DotNet.NativeWrapper/Interop.cs#L60).
I am unsure if there is a straightforward way to leverage this existing fix, however, reimplementing the second part isn't difficult and would at least provides users with a workaround by specifying the HOSTFXR_PATH variable. A draft PR with a potential implementation can be found here: #209. (note, I don't think this a full solution)