Doesn't work on Apple M2

[bartofzo]

Found out about this trying to build a docfx project on my MBP: https://github.com/dotnet/docfx/issues/8502#issue-1620402347

When running a .NET core console app and calling MSBuildLocator.RegisterDefaults() I get the following exception:

Unhandled exception. System.InvalidOperationException: Failed to find an appropriate version of .NET Core MSBuild. Call to hostfxr_resolve_sdk2 failed. There may be more details in stderr. 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() at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable1 source, Boolean& found) at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable1 source) at Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults() at Program.

OS: MacOS ventura 13.2.1, Apple M2 Pro Never had this problem on an Intel machine so I suspect it is due to that. Any fix or workaround available?

[Forgind]

Can you check if your dotnet executable is on your PATH? And if it's a symlink, can you make sure its target is the right dotnet?

[bartofzo]

I think it is, but I'm no expert at these kinds of things. If i run dotnet --info from a terminal I get the following information:

`Runtime Environment: OS Name: Mac OS X OS Version: 13.2 OS Platform: Darwin RID: osx.13-arm64 Base Path: /opt/homebrew/Cellar/dotnet/7.0.100/libexec/sdk/7.0.100/

Host: Version: 7.0.0 Architecture: arm64 Commit: d099f075e4

.NET SDKs installed: 7.0.100 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 7.0.0 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.0 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/shared/Microsoft.NETCore.App]

Other architectures found: x64 [/usr/local/share/dotnet/x64] registered at [/etc/dotnet/install_location_x64]

Environment variables: DOTNET_ROOT [/opt/homebrew/Cellar/dotnet/7.0.100/libexec] `

Does that help?

[Forgind]

dotnet --info is somewhat smarter in finding an appropriate SDK...I've been thinking recently about how to adopt some of their tactics.

Can you try changing you PATH just before invoking MSBuildLocator?

Specifically, I think your dotnet executable should be in one of the folders above where it found the SDK, so something like /opt/homebrew/Cellar/dotnet/7.0.100/libexec. Can you change PATH via export PATH=/opt/homebrew/Cellar/dotnet/7.0.100/libexec:$PATH

then try RegisterDefaults?

[nicolaiarocci]

I have the same problem on a M2:

# Program.cs
Microsoft.Build.Locator.RegisterDefaults();

$ dotnet run
System.TypeInitializationException: The type initializer for 'Microsoft.DocAsCode.Dotnet.DotnetApiCatalog' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'hostfxr' or one of its dependencies. 

$ export PATH="$(brew --prefix)/opt/dotnet/libexec:$PATH"
$ dotnet run
System.TypeInitializationException: The type initializer for 'Microsoft.DocAsCode.Dotnet.DotnetApiCatalog' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'hostfxr' or one of its dependencies. 

So adding the brew install path to PATH does not seem to help.

$ dotnet --info
.NET SDK:
 Version:   7.0.202
 Commit:    6c74320bc3

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.2
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.202/

Host:
  Version:      7.0.4
  Architecture: arm64
  Commit:       0a396acafe

.NET SDKs installed:
  7.0.202 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

$ brew info dotnet
Warning: Treating dotnet as a formula. For the cask, use homebrew/cask/dotnet
==> dotnet: stable 7.0.100 (bottled)
.NET Core
https://dotnet.microsoft.com/
/opt/homebrew/Cellar/dotnet/7.0.100 (2,943 files, 481.8MB) *
  Poured from bottle using the formulae.brew.sh API on 2023-04-05 at 11:45:58
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/dotnet.rb
License: MIT
==> Dependencies
Build: cmake ✘, pkg-config ✘, python@3.11 ✔
Required: icu4c ✔, openssl@1.1 ✔
==> Caveats
For other software to find dotnet you may need to set:
  export DOTNET_ROOT="/opt/homebrew/opt/dotnet/libexec"

zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions
==> Analytics
install: 96 (30 days), 7,926 (90 days), 50,256 (365 days)
install-on-request: 92 (30 days), 8,318 (90 days), 46,609 (365 days)
build-error: 0 (30 days)

[Forgind]

Our check is very direct with looking for dotnet at the exact spot as indicated on the path, so if it's under that spot, it won't work. Where is your dotnet executable? My suggestion looks like it included a version, which I don't see in the path you added to your PATH.

[Akronae]

I have the same issue using the VSCode C# extension

Might be related to https://github.com/dotnet/vscode-csharp/issues/6052 though

[bartofzo]

dotnet --info is somewhat smarter in finding an appropriate SDK...I've been thinking recently about how to adopt some of their tactics.

Can you try changing you PATH just before invoking MSBuildLocator?

Specifically, I think your dotnet executable should be in one of the folders above where it found the SDK, so something like /opt/homebrew/Cellar/dotnet/7.0.100/libexec. Can you change PATH via export PATH=/opt/homebrew/Cellar/dotnet/7.0.100/libexec:$PATH

then try RegisterDefaults?

Doesn't work. Still the same error.

[Dorbmon]

I got same problem on Apple M2pro

[montoulieu]

Same here on a M2 Ultra. Works fine on my M1 Max MacBook.

[YuliiaKovalova]

This one can be related to this issue https://github.com/dotnet/msbuild/issues/9038

@montoulieu , @Dorbmon , may I ask you to probe this workaround while we are working on the complex fix? https://github.com/microsoft/vscode-dotnettools/issues/120#issuecomment-1640892593

[YuliiaKovalova]

The issue is fixed. Pending release.

[TownshendHill]

Apologies, but I have the same exact issue happening, only that it's on Apple M1 Max.

Reference: dotnet --version 7.0.100

dotnet --info
.NET SDK:
 Version:   7.0.100
 Commit:    e12b7af219

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.5
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /opt/homebrew/Cellar/dotnet/7.0.100/libexec/sdk/7.0.100/

Host:
  Version:      7.0.0
  Architecture: arm64
  Commit:       d099f075e4

.NET SDKs installed:
  7.0.100 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.0 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.0 [/opt/homebrew/Cellar/dotnet/7.0.100/libexec/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  DOTNET_ROOT       [/opt/homebrew/Cellar/dotnet/7.0.100/libexec]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Notes:

• I can run dotnet commands directly on terminal with no issues, but when run with vscode, below popup appears:

• VScode is unable to create any new projects (nothing happens like this issue)
• When opening a folder containing .cs and .csproj files, there is no Solution Explorer

Please let me know if there's further testing needed on my end, or to open a new issue. Cheers.

[YuliiaKovalova]

Hi @TownshendHill,

Thank you for reporting it. The described issue seems to be related to this ticket from the extension repo: https://github.com/dotnet/vscode-csharp/issues/6461

There is no requested work for MSBuildLocator so far, so please track the progress in the referenced bug.