Consider enabling EnforceCodeStyleInBuild in runtime to validate IDE rules on build

[ViktorHofer]

See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-7#enable-on-build

IDEXXXX rules aren't validated in a dotnet build. Should we enable that validation by setting the EnforceCodeStyleInBuild property?

As an example, license headers aren't validated outside of a design time build inside VS:

runtime/eng/CodeAnalysis.src.globalconfig

Lines 1734 to 1735 in 2454fe6

	# IDE0073: The file header is missing or not located at the top of the file
	dotnet_diagnostic.IDE0073.severity = warning

Related:

• Enable more style checking analyzers #78414
• Format usings to match code style #94085

@stephentoub @akoeplinger

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-7#enable-on-build

IDEXXXX rules aren't validated in a dotnet build. Should we enable that validation by setting the EnforceCodeStyleInBuild property?

@stephentoub @akoeplinger

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure-mono
Milestone:	-

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-7#enable-on-build

IDEXXXX rules aren't validated in a dotnet build. Should we enable that validation by setting the EnforceCodeStyleInBuild property?

@stephentoub @akoeplinger

Author:	ViktorHofer
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[ViktorHofer]

cc @jkotas as this relates to #94085 on which you just commented.

[stephentoub]

IDEXXXX rules aren't validated in a dotnet build
As an example, license headers aren't validated outside of a design time build inside VS:

This is not the case. I just tried removing a header, and IDE0073 triggered with a dotnet build at the command-line.

We explicitly reference the nuget package containing many of the VS IDE analyzers:

runtime/eng/Analyzers.targets

Line 24 in 622f34e

<PackageReference Include="Microsoft.CodeAnalysis.CSharp.CodeStyle" Version="$(MicrosoftCodeAnalysisCSharpCodeStyleVersion)" PrivateAssets="all" />

so we get those regardless of whether VS is installed or EnforceCodeStyleInBuild is being used.

It may not be all of them, but it's many of them, and I believe it's most (if not all?) of those we have configured as warnings.

I don't know what the difference is between using that nuget and setting EnforceCodeStyleInBuild.

[akoeplinger]

Interesting, looks like that package overrides the built-in codestyle rules:

From what I can see we redistribute that package inside of the SDK so the behavior is the same (modulo version differences): https://github.com/dotnet/sdk/blob/fcc367b2164e4b41b8fb6622110aeb9f3247dd92/src/Layout/redist/redist.csproj#L39

So yeah looks like we don't need to set EnforceCodeStyleInBuild.

[ViktorHofer]

Thanks for checking. I didn't know that referencing the package overrides that setting. That's why I had to set the property in a different repository but not in runtime.