format: Dotnet format cannot find MSBuild on SDK 7.0.101

@craigktreasure i’ve tried with 7.0.103 and it results in the same problem 😦 it would be great to get some feedback from the dotnet devs, do we know they’re even aware of this issue?

Still an issue on the 8.0-preview image as well:

> docker run --rm -it mcr.microsoft.com/dotnet/sdk:8.0-preview-alpine3.17 sh -c "mkdir /tmp/test && cd /tmp/test && dotnet new console && dotnet format"
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /tmp/test/test.csproj:
  Determining projects to restore...
  Restored /tmp/test/test.csproj (in 62 ms).
Restore succeeded.


Unable to locate MSBuild. Ensure the .NET SDK was installed with the official installer.

Note that 7.0.200 has no Docker image published yet (see https://github.com/dotnet/dotnet-docker/discussions/4434), so can’t test behavior for that.

Running this locally on MacOS with dotnet version

dotnet --version
7.0.102

And getting same issue

➜ dotnet format -v diag
  The dotnet runtime version is '7.0.2'.
  The dotnet CLI version is '7.0.102'.
Unable to locate MSBuild. Ensure the .NET SDK was installed with the official installer.

This seems to be resolved in the latest stable Alpine image sdk version (mcr.microsoft.com/dotnet/sdk:7.0.305-alpine3.18 and also the .304 variant), however it is still present on the latest 8.0 preview version (mcr.microsoft.com/dotnet/sdk:8.0-preview-alpine3.18).

Still an issue on mcr.microsoft.com/dotnet/sdk:7.0.203-alpine3.17. I added the following line to my Dockerfile just before invoking the dotnet format command as a workaround:

RUN ln -s /usr/share/dotnet/host/fxr/7.0.5/libhostfxr.so /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.5/libhostfxr.so

I’m not an expert, but it seems that the release/7.x branch is in working condition. I built and installed it locally and it works for me. However, there’s not a build for the latest from that branch in the .NET 7 NuGet feed (https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json). Feels like they need to spin a new build and for the SDK to pick it up. Not sure how often that happens.

To some extent, I kinda wish support would go back to the dotnet-format tool so that it could rev in times like this. It’s valuable to those of us that use it, but it’s clearly not getting the attention it deserves despite it being integrated into the SDK. Quite unfortunate.

Getting the same issue in alpine 7.0.103-alpine3.17

I got this issue on mcr.microsoft.com/dotnet/sdk:7.0.102-alpine3.17 and traced it.

For some reason, MSBuildLocator does not find libhostfxr.so (which is in /usr/share/dotnet/host/fxr/7.0.2/). From the trace, it tries to load it from the following paths:

/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.2/hostfxr.so
/usr/share/dotnet/sdk/7.0.102/DotnetTools/dotnet-format/hostfxr.so
/lib/hostfxr.so
/usr/local/lib/hostfxr.so
/usr/lib/hostfxr.so
/usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.2/libhostfxr.so
/usr/share/dotnet/sdk/7.0.102/DotnetTools/dotnet-format/libhostfxr.so
/lib/libhostfxr.so
/usr/local/lib/libhostfxr.so
/usr/lib/libhostfxr.so

On dotnet/sdk:6.0.405-alpine3.17 it is loaded directly from /usr/share/dotnet/host/fxr/6.0.13/libhostfxr.so without even looking in other directories. Also, dotnet/sdk:7.0.102 (debian) works fine, so it must be specific to alpine.

Adding a symlink in the sdk directory works as a workaround until it is fixed.

ln -s /usr/share/dotnet/host/fxr/7.0.2/libhostfxr.so /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.2/libhostfxr.so

Still an issue on mcr.microsoft.com/dotnet/sdk:7.0.102-alpine3.17 with dotnet format version 7.0.357101+49c2ef651359526841d13e66129b71d1bcd9cef9