2.0 package shouldn't bring in vs-threading analyzers

[AArnott]

@jakebailey reports that installing the 2.0.102-beta package also installed the vs-threading analyzers to his project. This shouldn't happen.

[AArnott]

I can't find anything wrong with what we're doing. Yet I've verified the problem repros.

Filed: https://github.com/NuGet/Home/issues/7426

[AArnott]

Now tracked by: https://github.com/NuGet/Home/issues/6279

[joshlang]

Just posting my support for this... cus it's driving me nuts. The analyzers are like a virus. Everything we do is Async. We shouldn't be forced into adding "Async" on the end of every method on 100+ projects in a solution just because we use StreamJsonRpc. Will go rant in the nuget bug too :)

[AArnott]

Will go rant in the nuget bug too :)

Yes, thanks for that. Also as a workaround you can suppress the warnings created by those particular analyzers. Either by creating a .ruleset file that all of your projects use or by defining a Directory.Build.props file in the root of your repo with something like this:

<PropertyGroup>
  <NoWarn>$(NoWarn);VSTHRD100</NoWarn>
</PropertyGroup>

[joshlang]

Thanks! <NoWarn>$(NoWarn);VSTHRD200</NoWarn> works beautifully, but I won't tell the nuget folks. I already committed to going bonkers.

[flcdrg]

I'm guessing this is because https://www.nuget.org/packages/Microsoft.VisualStudio.Threading/15.8.209 has a dependency on https://www.nuget.org/packages/Microsoft.VisualStudio.Threading.Analyzers/

Interestingly, for the 16.x release of Microsoft.VisualStudio.Threading, that dependency has been removed.

[AArnott]

Interestingly, for the 16.x release of Microsoft.VisualStudio.Threading, that dependency has been removed.

That was a mistake tracked by https://github.com/microsoft/vs-threading/issues/483

[jmalczak]

So what's the current state of this issue? We have started using jsonrpc and it brought threading analyzers. We use rider on mac os as a development IDE and there is no way to disable those analyzers during build time in IDE. Now build time for our solution is more than then double the previous time.

[AArnott]

So what's the current state of this issue?

We're still waiting on the NuGet feature team to provide a fix.

there is no way to disable those analyzers during build time in IDE

You should be able to suppress analyzers in any of several ways:

1. set ExcludeAssets="analyzers" on your PackageReference to StreamJsonRpc.
2. provide a ruleset file that disables the individual rules.
3. use an .editorconfig file to disable the individual rules.

[jmalczak]

Thanks for the reply, unfortunately ExcludeAssets didn't work for me. I have found another issue that tracks issue with this attribute. Disabling individual rules is a pain so I have found another way of disabling analyzers:

<Target Name="DisableAnalyzersForVisualStudioBuild"
        BeforeTargets="CoreCompile">
    <!--
      Disable analyzers when building a project inside Visual Studio. Note that analyzer behavior for IntelliSense
      purposes is not altered by this.
    -->
    <ItemGroup>
        <Analyzer Remove="@(Analyzer)"/>
    </ItemGroup>
</Target>

This disable all analyzers but may be tweaked to remove just certain types.

[bddckr]

If you are going for the nuke option that is disabling all analyzers you can also just use

<PropertyGroup>
  <RunAnalyzersDuringLiveAnalysis>false</RunAnalyzersDuringLiveAnalysis>
  <RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
</PropertyGroup>

[jmalczak]

This option didn't work for me either. I use macos and both Rider and Visual Studio ignore those settings on macos.

[AArnott]

I don't think macos would be different here. What are you building with? dotnet build ? Msbuild? Xbuild?

[AArnott]

I also wonder if adding a package reference to the threading analyzer package directly and setting the ExcludeAssets on that would work.

[jmalczak]

I have tried it and it didn't work. I have also tried adding reference to threading analyzers directly with excludeassets and that didn't work as well. Probably the reason was that I have a solution with both asp.net core and xamarin native so msbuild from mono is used to build those projects. I have noticed that mono uses older msbuild 15 while dotnet build on just asp.net project uses msbuild 16.

[Kuling]

Hi I got hit by the same problem. In my case it effectively prevents us from upgrading StreamJsonRpc from 2.8.28 to any higher version.

Configuration:

• Visual Studio 2022 17.4.1.
• Solution with ~260 csproj. StreamJsonRpc is our very low depenency.
• NET 5 for StreamJsonRpc server.
• netstandard2.0 for StreamJsonRpc client library.
• Rest of projects mostly in .NET 4.7.2/netstandard2.0.
• One target x64/Windows.
• Built on server via msbuild. Version: "MSBuild version 17.4.0+18d5aef85 for .NET Framework"

On the same physical build server we have such build times:

• 4:30 with StreamJsonRpc 2.8.28/NET 5
• 2:11 with StreamJsonRpc 2.8.28/NET 5 and analyzers disabled globally via Directory.Build.Props/<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
• 10:15 with StreamJsonRpc 2.9.85/NET 5
• 2:10 with StreamJsonRpc 2.9.85/NET 5 and analyzers disabled globally via Directory.Build.Props/<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
• 10:12 with StreamJsonRpc 2.13.33/NET 5
• 2:03 with StreamJsonRpc 2.13.33/NET 5 and analyzers disabled globally via Directory.Build.Props/<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
• 10:06 with StreamJsonRpc 2.13.33/NET 6
• 2:02 with StreamJsonRpc 2.13.33/NET 6 and analyzers disabled globally via Directory.Build.Props/<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>

ExcludeAssets="analyzers" has no effect. I haven't tried .editorconfig exclusions yet.

I understand that the real fix should be made in Nuget infrastructure to stop inherit analyzers. But maybe you could consider removing dependency to analyzers until this functionality will be available.

[AArnott]

consider removing dependency to analyzers until this functionality will be available.

That's just the problem (with NuGet). We can't. We have no dependency on analyzers. They come transitively through the Microsoft.VisualStudio.Threading dependency, which is absolutely one that we cannot drop.

Fixing your build times shouldn't require disabling all analyzers. Any means of suppressing just one should be sufficient. In particular, I believe it is VSTHRD010 that is super slow. If you disable that (via .editorconfig, NoWarn, etc.) that should be adequate.

[Kuling]

Thank you. Works like a charm.

We had suggestion level set for all VSTHRD warnings. Setting only VSTHRD010 to none was not enough in our case.

Setting all warnings to level none reduced build time to healthy value. I'll try to adjust levels later.

• 4:04 with StreamJsonRpc 2.13.33/NET 6 with all VSTHRD* set to none

In case somebody needs it.

# VSTHRD001: Avoid legacy thread switching methods.
dotnet_diagnostic.VSTHRD001.severity = none

# VSTHRD002: Synchronously waiting on tasks or awaiters may cause deadlocks. Use await or JoinableTaskFactory.Run instead.
dotnet_diagnostic.VSTHRD002.severity = none

# VSTHRD003: Avoid awaiting foreign Tasks.
dotnet_diagnostic.VSTHRD003.severity = none

# VSTHRD004: Await SwitchToMainThreadAsync.
dotnet_diagnostic.VSTHRD004.severity = none

# VSTHRD010: Invoke single-threaded types on Main thread.
dotnet_diagnostic.VSTHRD010.severity = none
 
# VSTHRD011: Use AsyncLazy<T>.
dotnet_diagnostic.VSTHRD011.severity = none

# VSTHRD012: Provide JoinableTaskFactory where allowed.
dotnet_diagnostic.VSTHRD012.severity = none

# VSTHRD100: Avoid "async void" methods, because any exceptions not handled by the method will crash the process.
dotnet_diagnostic.VSTHRD100.severity = none

# VSTHRD101: Avoid using async lambda for a void returning delegate type, because any exceptions not handled by the delegate will crash the process.
dotnet_diagnostic.VSTHRD101.severity = none

# VSTHRD102: Implement internal logic asynchronously.
dotnet_diagnostic.VSTHRD102.severity = none

# VSTHRD103: Call async methods when in an async method.
dotnet_diagnostic.VSTHRD103.severity = none

# VSTHRD104: Expose an async version of this method that does not synchronously block. Then simplify this method to call that async method within a JoinableTaskFactory.Run delegate.
dotnet_diagnostic.VSTHRD104.severity = none

# VSTHRD105: Avoid method overloads that assume TaskScheduler.Current. Use an overload that accepts a TaskScheduler and specify TaskScheduler.Default (or any other) explicitly.
dotnet_diagnostic.VSTHRD105.severity = none

# VSTHRD106: Use InvokeAsync to raise async events.
dotnet_diagnostic.VSTHRD106.severity = none

# VSTHRD107: Await Task within using expression.
dotnet_diagnostic.VSTHRD107.severity = none

# VSTHRD108: Assert thread affinity unconditionally.
dotnet_diagnostic.VSTHRD108.severity = none

# VSTHRD109: Switch instead of assert in async methods.
dotnet_diagnostic.VSTHRD109.severity = none

# VSTHRD110: Observe the awaitable result of this method call by awaiting it, assigning to a variable, or passing it to another method.
dotnet_diagnostic.VSTHRD110.severity = none

# VSTHRD111: Add .ConfigureAwait(bool) to your await expression.
dotnet_diagnostic.VSTHRD111.severity = none

# VSTHRD112: Implement System.IAsyncDisposable.
dotnet_diagnostic.VSTHRD112.severity = none

# VSTHRD113: Check for System.IAsyncDisposable.
dotnet_diagnostic.VSTHRD113.severity = none

# VSTHRD114: Avoid returning a null Task.
dotnet_diagnostic.VSTHRD114.severity = none

# VSTHRD200: Use "Async" suffix in names of methods that return an awaitable type.
dotnet_diagnostic.VSTHRD200.severity = none

[AArnott]

Thanks for sharing, @kuling. If you ever find out which specific analyzers slow down your build, please let us know over at the microsoft/vs-threading repo! (and feel free to share here as well).

[Kuling]

It appears that disabling VSTHRD110 is enough

• 4:25 with StreamJsonRpc 2.13.33/NET 6 with VSTHRD110 set to none

There is already bug reported for it https://github.com/microsoft/vs-threading/issues/971 In my case microsoft.visualstudio.threading.analyzers was upgraded from 16.9.60 to 17.1.46.