dotnet format is broken on sdk 7.0.200 if EnforceCodeStyleInBuild is set to true – Could not load file or assembly 'Microsoft.CodeAnalysis'

[askazakov]

step to reproduce

• create new project

dotnet new console

• add <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> to .csproj

• add global.json

dotnet new globaljson

• change sdk version in global.json to "7.0.103"
• run

dotnet format

everything is ok here.

• change sdk version in global.json to "7.0.200"
• run

dotnet format

and now there are a lot of

Unhandled exception: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types.
Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

in output

[askazakov]

dotnet --info
.NET SDK:
 Version:   7.0.200
 Commit:    534117727b

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

Host:
  Version:      7.0.3
  Architecture: x64
  Commit:       0a2bda10e8

[tidusjar]

Same is happening for me and all of my colleagues

.NET SDK:
 Version:   7.0.200
 Commit:    534117727b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.200\

Host:
  Version:      7.0.3
  Architecture: x64
  Commit:       0a2bda10e8

[si618]

Thanks for the heads-up, confirmed and if nothing else a good excuse to move to Directory.Build.Props

[zh6335901]

I had the same problem

[m3nax]

Same here

[panicoenlaxbox]

Idem, with dotnet --version 7.0.200.
@si618 Have I understood that there is workaround with Directory.Build.props? I've tried it and it doesn't work either.
Thank you.

[si618]

@si618 Have I understood that there is workaround with Directory.Build.props? I've tried it and it doesn't work either. Thank you.

Commenting out EnforceCodeStyleInBuild as per linked commit worked for me.

Not really a workaround per se, just skipping until fixed, but having it in Directory.Build.props means only changing one file.

[panicoenlaxbox]

Ok, thank you, I hope it will be fixed soon.

[RikkiGibson]

I suspect that this is caused by dotnet-format's reference to the compiler getting out of date. #1782

[glen-84]

@RikkiGibson Do you know if there are plans to assign a new maintainer to this project?

[MrcnPnkrsk]

Is there any Road Map for fixing this issue?

.NET 7.0.4 is installed automatically with Visual Studio 2022 and for the past 4 months bundled dotnet-format is unusable.
#1782 Seems to be forgotten.

[GGG-KILLER]

I've been getting this using .NET 8 in a dev container where .NET was installed using dotnet-install.sh.

The project it runs into an exception while trying to format is an Incremental Source Generator.

Solution: https://github.com/LorettaDevs/Loretta (devcontainer files are contained within)
Project: Loretta.Generators.SyntaxFactsGenerator
Format command: dotnet format (v8.0.405501+2cb3e68c6b9a966114572fd63f2a20d2cb54a288)
Output: https://gist.github.com/GGG-KILLER/81a9773f7c02a12a841edd331751d2ee

dotnet --info

$ dotnet --info
.NET SDK:
 Version:   8.0.100-preview.2.23157.25
 Commit:    54801b2435

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/local/dotnet/current/sdk/8.0.100-preview.2.23157.25/

Host:
  Version:      8.0.0-preview.2.23128.3
  Architecture: x64
  Commit:       30b879924a

.NET SDKs installed:
  6.0.407 [/usr/local/dotnet/current/sdk]
  7.0.202 [/usr/local/dotnet/current/sdk]
  8.0.100-preview.2.23157.25 [/usr/local/dotnet/current/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.15 [/usr/local/dotnet/current/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.4 [/usr/local/dotnet/current/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.2.23153.2 [/usr/local/dotnet/current/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.15 [/usr/local/dotnet/current/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.4 [/usr/local/dotnet/current/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.2.23128.3 [/usr/local/dotnet/current/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

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

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

[avidenic]

This seems to be an issue on 7.0.202 and 7.0.203 as well.

[arunchndr]

Thanks for that! Is there any way to get automated tests for this? I think this is the second or third time dotnet format has broken completely since 6.0 for roughly the same reason.

Absolutely yes for the integration test gap that needs to be filled. @sharwell to comment on the global json support.

[sharwell]

dotnet format runs from a self-contained folder on disk. Whatever code dotnet uses to determine the binary to run for the format command is what determines the SDK that provides the format implementation. This seems like a question for the dotnet CLI about why it isn't accounting for global.json.

[JoeRobich]

MSBuildLocator should be returning the pinned SDK first, if it was installed.

format/src/Commands/FormatCommandCommon.cs

Lines 350 to 352 in c99dcfe

	var msBuildInstance = Build.Locator.MSBuildLocator.QueryVisualStudioInstances()
	.Where(instance => instance.Version.Major >= 6)
	.FirstOrDefault();

Ideally, since the CLI launches the dotnet-format tool from the globla.json pinned SDK folder and the SDK has a particular layout, the tool would be updated to find the proper MSBuild using relative paths.

[idilov]

Both this problem and dotnet/sdk#32598 seem to have been fixed in sdk 7.0.304.
I re-enabled EnforceCodeStyleInBuild, removed all workarounds and downgrades which I had been using for 4 months and can once again enjoy dotnet format as is. Hope it's not just me. Thank you!

[brminnick]

Both this problem and dotnet/sdk#32598 seem to have been fixed in sdk 7.0.304.

Awesome!! Yup, I can confirm that we can now use dotnet format again with no errors in our .NET Community Toolkit libraries

[JoeRobich]

@brminnick Thanks for the confirmation! Closing.