RS1022 slowing down build of non-analyzer project

[ghosttie]

Analyzer

Diagnostic ID: RS1022: Do not use types from Workspaces assembly in an analyzer

Analyzer source

SDK: Built-in CA analyzers in .NET 7 SDK or later

Version: SDK 7.0.400-preview.23225.8

Describe the bug

I was trying to debug why builds of my application take a really long time.

If I delete my .editorconfig file, the build is fast, so I figured the problem was an analyzer.

I followed the instructions here to run msbuild with logging enabled, to see which analyzers were taking all of the time. Almost all of the build time is taken up by one analyzer:

Microsoft.CodeAnalysis.CSharp.Analyzers.MetaAnalyzers.CSharpDiagnosticAnalyzerApiUsageAnalyzer (RS1022) = 2:15.691

RS1022 appears to be intended to analyze analyzer projects, but my application isn't an analyzer, it's an ASP.NET Core MVC app, so I don't know why it's even running.

I don't have any analyzer nuget packages installed and setting dotnet_diagnostic.RS1022.severity = none in .editorconfig didn't turn it off.

Steps To Reproduce

I can reproduce this every time I build my application, but I don't know what's causing it so I can't tell you how to reproduce it.

[sharwell]

This was also filed as AB#1837711.

The root cause of the performance overhead of RS1022 is it incorrectly defaults to permissive mode (it allows a DiagnosticAnalyzer, DiagnosticSuppressor, ISourceGenerator, or IIncrementalGenerator to be implemented in an assembly which contains a compile-time reference to the workspaces layer). The permissive mode of this analyzer performs a deep analysis of these types to ensure they do not contain any references to the workspaces layer from inside that type.

The fix for this issue is to modify the default behavior of this analyzer to be strict:

• Strict mode (default)
  • Diagnostic reported if compile-time extension is defined in assembly that references workspaces layer
  • Diagnostic reported if compile-time extension declares support for C# language in assembly that references Microsoft.CodeAnalysis.VisualBasic
  • Diagnostic reported if compile-time extension declares support for Visual Basic language in assembly that references Microsoft.CodeAnalysis.CSharp
• Permissive mode (enabled by .editorconfig option)
  • Reverts to current slow behavior

[sharwell]

In the binlog provided on the feedback ticket, I determined that the analyzer is introduced indirectly by the Microsoft.VisualStudio.Web.CodeGeneration.Design NuGet package. Prior to the implementation of strict mode described above, the performance overhead of this analyzer can be avoided by disabling RS1022 in the .editorconfig file for the project.

[ghosttie]

I set dotnet_diagnostic.RS1022.severity = none in .editorconfig but it didn't turn it off - RS1022 still took 2/3 of the build time

[sharwell]

You may need to set it in .globalconfig instead of .editorconfig.

[ghosttie]

I've created a .globalconfig file in the solution folder containing

is_global = true

dotnet_diagnostic.RS1022.severity = none

but it doesn't seem to be working. As far as I can tell from the documentation it should be working:

if you name these files as .globalconfig, then they are implicitly applied to all the C# and Visual Basic projects within the current folder, including subfolders

[mavasani]

If I delete my .editorconfig file, the build is fast, so I figured the problem was an analyzer.

Can you please share your .editorconfig file? I am curious how deleting it causing the build to be faster

[ghosttie]

Sorry, my comment about deleting .editorconfig was inaccurate.

In this solution the problem is RS1022 but in another solution I was investigating the problem was other slow analyzers that I was able to just turn off (which is why deleting the .editorconfig sped it up in that case).

.editorconfig.zip

The list of disabled analyzers is at the end of the file.

[ghosttie]

Is not being able to turn RS1022 off using .editorconfig or .globalconfig a bug?

[mavasani]

Is not being able to turn RS1022 off using .editorconfig or .globalconfig a bug?

Yes, definitely. Can you please file a separate issue for it? Thanks for bringing it to our notice.

[ghosttie]

What's the ETA on vNext, since I don't have a workaround for this?

[mavasani]

What's the ETA on vNext, since I don't have a workaround for this?

@ghosttie - meanwhile, you can reference the latest prerelease version from this public feed: https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet8/NuGet/Microsoft.CodeAnalysis.Analyzers

[ghosttie]

This is still happening in .NET 8

[sharwell]

Hi @ghosttie,

I believe RS1022 is disabled by default in .NET 8. If you are experiencing issues with this analyzer, it sounds like a project is either referencing an old version of the analyzer package, or the project configuration has been updated to explicitly enabled RS1022. Can you collect a .binlog for your build by passing /bl to the compiler, and then attach that file to a new issue submitted through the Report a Problem tool in Visual Studio?

[ghosttie]

I don't see any analyzers included in any of the project files and my .editorconfig doesn't have RS1022 in it, is there somewhere else I should be looking?

If I'm reading this correctly, Microsoft.VisualStudio.Web.CodeGeneration.Design has transitive dependencies on Microsoft.CodeAnalysis.CSharp v4.8 and Microsoft.CodeAnalysis.Razor v6 - could those be the problem?

Also adding

dotnet_diagnostic.RS1022.severity = none

to .editorconfig doesn't seem to make a difference so I'm not sure #33696 is fixed

[sharwell]

Hi @ghosttie,

We would need to see a .binlog or a reproducing solution in order to investigate further. These can be submitted through the feedback system to avoid posting the information publicly. Thanks!

[ghosttie]

OK I attached the binlog to this feedback

[sharwell]

Hi @ghosttie,

Thank you for providing that information. It appears that the following sequence of dependencies leads to this problem:

Microsoft.VisualStudio.Web.CodeGeneration.Design/8.0.0
→ Microsoft.VisualStudio.Web.CodeGenerators.Mvc/8.0.0
→ Microsoft.VisualStudio.Web.CodeGeneration/8.0.0
→ Microsoft.VisualStudio.Web.CodeGeneration.EntityFrameworkCore/8.0.0
→ Microsoft.VisualStudio.Web.CodeGeneration.Core/8.0.0
→ Microsoft.VisualStudio.Web.CodeGeneration.Templating/8.0.0
→ Microsoft.VisualStudio.Web.CodeGeneration.Utils/8.0.0
→ Microsoft.CodeAnalysis.CSharp.Workspaces/4.8.0-3.final
→ Microsoft.CodeAnalysis.Workspaces.Common/4.8.0-3.final
→ Microsoft.CodeAnalysis.Common/4.8.0-3.final
→ Microsoft.CodeAnalysis.Analyzers/3.3.4 ❌

You'll need to force Microsoft.CodeAnalysis.Analyzers to use a newer version in one of the following two ways:

1. If you switch to Central Package Management, you can add a <PackageVersion> item for the Microsoft.CodeAnalysis.Analyzers package.
2. Otherwise, you can manually add a <PackageReference> item for a newer version of Microsoft.CodeAnalysis.Analyzers to override the one that is getting included by default.

[ghosttie]

On NuGet it looks like 3.3.4 is the latest version of Microsoft.CodeAnalysis.Analyzers

[ghosttie]

So there is no newer version of the package to upgrade to - can you verify that it's fixed in Microsoft.CodeAnalysis.Analyzers 3.3.4?

[sharwell]

@ghosttie This was answered above:
#6676 (comment)

The latest versions are now going to this feed:
https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet9/NuGet/Microsoft.CodeAnalysis.Analyzers

The feed changes when we start working on a new version of .NET.

[ghosttie]

Sorry, I didn't realize the CodeAnalysis had a separate release cycle from .NET, I assumed it would have been released with .NET 8

I can confirm that it is fixed in 3.11