Roslyn-analyzers: Getting CA0055 and CA0052 errors with .NET Core 2.0 Projects

[Petermarcu]

@dvm-2k1 reported this here: https://github.com/dotnet/core/issues/758#issuecomment-335075221

Please let me know Is this CA0055 and CA0052 issues got resolved for .Net Core 2.0 (netcoreapp2.0) projects?

Asking this because I'm still getting these errors when enabled our .Net Core 2.0 projects to use code analysis ruleset which are defined for our projects and trying to build from Visual Studio 2017 (updated to 15.3.5 version) and by using MSBuild command.

As per this conversion thread, I've installed Nuget package of Microsoft.CodeAnalysis.FxCopAnalyzers to our .net core 2.0 projects, but still getting CA0055 and CA0052 errors. Please help me out to resolve these issues which are blocking our builds.

[dvm-2k1]

Thanks @Petermarcu for posting this issue to right forums...

[dvm-2k1]

This issue can marked as resolved as these issues got fixed in our .Net Core 2.0 projects.

Cause of the errors:
_Note: This was written based on my investigation and understandings of MSBuild execution behavior of .Net Core projects to standard .Net Framework projects._

These issues were coming as "RunCodeAnalysis" flag was set to true which was coming from our Build props file, if csproj file does not have this element in them. If this "RunCodeAnalysis" flag is set to true this is executing FxCop command explicitly by MSBuild and FxCop is not getting any hint about targets details for .Net Core framework it is raising these CA0055 and CA0052 errors.

However, .Net Core implicitly executes code analysis rules with Code Analysis analyzers and this cannot be controlled by "RunCodeAnalysis" flag during build.

Fix for this errors:
Added "RunCodeAnalysis" element in PropertyGroup of csproj file to set to "false" so that this will hint MSBuild not to execute FxCop explicitly for .Net Core 2.0 or .Net Standard 2.0 projects.

<PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> ...... <RunCodeAnalysis>false</RunCodeAnalysis> </PropertyGroup>

[daviddunson]

I rely on CA2000 and this rule is mandatory on all of my builds. I cannot upgrade to Microsoft.CodeAnalysis.FxCopAnalyzers due to an exiting bug preventing this rule from being implemented. Because of this, I cannot run Code Analysis on any .NET Core application, or .NET Standard libraries 1.5 or greater.

If someone has a solution that allows me to run an equivalent (modern version) of the "Microsoft All Rules" rule set (including CA2000) on a .NET Standard 1.5 or greater library and on .NET Core applications, please let me know.

[mavasani]

Closing this issue as per https://github.com/dotnet/roslyn-analyzers/issues/1313#issuecomment-335415808

@daviddunson Please open another issue if you are still having trouble

[BioTurboNick]

I don't think this should be closed. The issue is that Code Analysis is failing. Disabling code analysis as per the noted comment appears to be a workaround, not a solution.

[emre-aki]

I am facing the same exact issue. When I configure the ruleset to my project as the default provided by Sonarqube, named 'The Sonar way', the project builds perfectly. However when I set the project ruleset to be a custom one, I get CA0055 and CA0052 and the build fails midway through the MSBuild 15.0 task.

I tried the workaround suggested by @dvm-2k1 but had no luck there.

[daviddunson]

The workaround that I am currently using until the FxCopAnalyzers is completed is to set to include at least one .NET Framework target (i.e. net40), and enable Code Analysis only on that target framework.

  <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)' == 'Debug|net40|AnyCPU'">
    <DebugType>full</DebugType>
    <RunCodeAnalysis>true</RunCodeAnalysis>
    <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)' == 'Release|net40|AnyCPU'">
    <DebugType>pdbonly</DebugType>
    <RunCodeAnalysis>true</RunCodeAnalysis>
    <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>

The disadvantage to this is that it will not catch any code that is not .NET Framework compliant (i.e. #if !NET40).

Do not enable Code Analysis on multiple target frameworks, or you will get multiple warnings in the error list. Do not enable Code Analysis on a .NET Standard framework greater than 1.4.

[samsmithnz]

is there another issue opened to fix the root cause (e.g. code analysis is enabled?) I agree with other posters that disabling code analysis is not a solution, it's a (hacky) workaround...

[333fred]

@samsmithnz, I'm not sure what you're asking for here. RunCodeAnalysis is part of the old FXCop framework, and we won't be fixing the CA0055/CA0052 errors in that analysis framework.

[samsmithnz]

Got it, I didn't understand that sorry.

It seems then that it's not possible to have Code Analysis enabled on the build in a solution with a mix of .Net Framework and .Net core assemblies?

[BioTurboNick]

Okay, so the root problem is really:

1. Code Analysis is being phased out in favor of Roslyn analyzers.
2. The UI in VS provides access to former but not the latter.
3. There's nothing to direct users away from the old model to the new model.
4. There's no discoverability/ease of use for the new model.

[mavasani]

@BioTurboNick That is the exact story that @333fred is currently investigating. Fred, do you have a tracking work item for the same?

Until the migration story is complete, please follow the below steps:

1. Add a NuGet package reference to https://www.nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers in your project. Refer to https://github.com/dotnet/roslyn-analyzers#recommended-version-of-analyzer-packages for choosing the right package version.
2. Do not manually invoke "Run Code Analysis" command or set RunCodeAnalysis MSBuild property to true in CI builds. Analyzers always get executed as part of command line builds during compilation and do not need any additional configuration or explicit invocation.
3. We have ported majority of the rules, but certain rules based on dataflow analysis have yet not been ported (https://github.com/dotnet/roslyn-analyzers/issues?q=is%3Aopen+is%3Aissue+label%3ADependency-DataFlow). We are working towards adding a non-dataflow based implementation of these rules in the FxCop analyzers package. In future, we want to improve the preciseness of these rules with dataflow analysis results.

[333fred]

I don't have tracking item for this at the moment, I'm planning on opening one after the holidays are over and we have a more complete plan of what experience we want is.

[MelbourneDeveloper]

This is still an issue in Visual Stdio 2017 - 15.5.7 With .NET Standard 2.0

This is frustrating like you wouldn't believe. I try to make sure our team follows the highest coding standards and yet we can't even get basic code rules functionality to work.

None of our .NET Standard 2.0 projects compile properly with code rules turned on. Even when they do compile, the broken code rules are never picked up.

It's about time Microsoft spent some time on the code analyzer. It's ridiculous that release after release of Visual Studio has meant that we can't even implement basic code rules in our projects without using workarounds.

[MelbourneDeveloper]

@mavasani , are you saying that we have to build our projects at the command line to get code rules to work?

When is this going to be fixed?

Year after year, the code analyzer has been neglected. There are bugs all over the place even when not using .NET Standard. Are Microsoft actually working to fix the issues?

[mavasani]

@MelbourneDeveloper I am sorry to hear about your issues. Please let me know if following helps:

1. The recommended approach to run Code Analysis on .netcore/.netstandard projects is explained here: https://github.com/dotnet/roslyn-analyzers/issues/1313#issuecomment-354491017.
2. You add a NuGet package reference to FxCopAnalyzers and then the analyzers run by default in VS IDE while you type, and automatically run within the compiler when you execute "Build" (either from the command line or within Visual Studio). Any violations from analysis are reported along with compiler diagnostics. You don't need to do anything special to execute code analysis, it is integrated into developer's regular workflow.
3. "Run Code Analysis" command is for executing legacy post-build analysis (FxCopCmd.exe), which is not supported for .netcore/.netstandard projects. You don't need to ever invoke it. We are hoping to soon deprecate/disable this command for managed projects as part of the FXCop migration story.

[danrien]

"Run Code Analysis" command is for executing legacy post-build analysis (FxCopCmd.exe), which is not supported for .netcore/.netstandard projects

Does this imply that roslyn analyzers do not work on .Net standard? Surely code quality is still important with .net standard?

[mavasani]

@danrien I believe you misread my comment. Roslyn analyzers do work fine on .net standard and .net core platforms. FxCopCmd.exe, which is a legacy binary analysis tool does not support these platforms.

[danrien]

Ah ok, thanks, I clearly misintrepreted!

By the way, for anyone reading this wondering how to use StyleCop, there are StyleCopAnalyzers, which I think has high compatibility with the original StyleCop...

[Styxxy]

I came across the same problem when having a solution mixed with .NET Full (non-SDK style projects) and .NET Standard projects (SDK style projects).

I fixed it by adding following _custom_ target at the end of the project (I actually created a shared targets file which I imports in each SDK style project):

  <Target Name="IgnoreRunCodeAnalysis" Condition=" '$(RunCodeAnalysis)' == 'true' " BeforeTargets="RunCodeAnalysis">
    <Message Importance="normal" Text="Set RunCodeAnalysisOnThisProject to false" />
    <PropertyGroup>
      <RunCodeAnalysisOnThisProject>false</RunCodeAnalysisOnThisProject>
    </PropertyGroup>
  </Target>

If you want code analysis, you can include the (nuget) package Microsoft.CodeAnalysis.FxCopAnalyzers. I did it like below (in my project files), so I can still leverage the global property RunCodeAnalysis:

  <ItemGroup Condition=" '$(RunCodeAnalysis)' == 'true' ">
    <PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.6.1" />
  </ItemGroup>

[sobolev88]

I don't know why, but if I add <GenerateDocumentationFile>true</GenerateDocumentationFile> msbuild runs code analysis and the build fails with IDE0005. It seems a solution for me

P.S.
I configured IDE0005 as an error in editorconfig, installed Microsoft.CodeAnalysis.CSharp.CodeStyle and I want to get errors from msbuild