dotnet format does not respect the .NET install location

[CollinAlpert]

I manage my own .NET installations and have the dotnet command aliased to the directory where I keep my installations. This works perfectly for dotnet run, dotnet build, dotnet pack etc. When running dotnet format however, I get the following error message:

No .NET SDKs were found.

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

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
Unable to locate MSBuild. Ensure the .NET SDK was installed with the official installer.

I am using macOS 13.4.1 with an M1 Pro.

[JoeRobich]

@CollinAlpert I would recommend setting DOTNET_ROOT to the directory where you keep your installation.

[CollinAlpert]

Unfortunately that did not work.

[NikolaMilosavljevic]

We've seen the same issue in .NET 8 on Linux. We had to disable related tests in 8.0 source-build due to this issue. We are setting DOTNET_ROOT.

I see that dotnet-format uses MSBuildLocator package for obtaining MSBuild path: https://github.com/dotnet/format/blob/c33a768fda4d406460dbf46bc1796b99942ab7ed/src/Commands/FormatCommandCommon.cs#L385C40-L385C40

MSBuildLocator has modified the code that obtains .NET SDK paths. This used to work in old MSBuildLocator version (1.4.x), but isn't working anymore in (1.5.5). It now requires dotnet command in the PATH.

7.0 version of dotnet-format uses an old MSBuildLocator package and works fine in all scenarios, i.e. supports DOTNET_ROOT scenario.

@Forgind it appears that this was regressed with https://github.com/microsoft/MSBuildLocator/pull/161

[JoeRobich]

We ship in the SDK and could save ourselves this hassle, if we used a relative path to the MSBuild libraries. The CLI should invoke the dotnet-format from the correct SDK with regards to global.json pinning.

[NikolaMilosavljevic]

We ship in the SDK and could save ourselves this hassle, if we used a relative path to the MSBuild libraries. The CLI should invoke the dotnet-format from the correct SDK with regards to global.json pinning.

That seems like a best long-term solution for dotnet-format. Would it still make sense to use existing code as fallback, for users that installed dotnet-format as a global tool - if that is even a supported scenario.

[Forgind]

You're correct that I didn't take into account DOTNET_ROOT when I made that PR. I made a follow-up here that should resolve that issue. Thanks for diagnosing this!