Inspections show hundreds of false positive errors while Resharper doesn't

Hello Adrian,

Could you please let me know if you have these errors filtered out on your ReSharper instance? Do you have corresponding project-level settings committed to a VCS root in question? If you have custom profile path configured, please share the screenshot of step configuration:

TeamCity is simply evoking InspectCode tool with no extra settings on top of solution file, output folder and --profile if specified. Inspections and errors/warnings list could be influenced by:
- project-level settings (ex. Samples.sln.DotSettings - it would be best to commit those to the repository)
- project-level user settings (ex. Samples.sln.DotSettings.user - those are local to user)
- user-level settings global for the specific machine (%AppData%\JetBrains\Shared\vAny\GlobalSettingsStorage.DotSettings)

You could find more regarding the settings here: https://www.jetbrains.com/help/resharper/Sharing_Configuration_Options.html
The difference in settings at the environment you are using for manual ReSharper run versus the one TeamCity agent uses could lead to the discrepancy you have described. (see https://confluence.jetbrains.com/pages/viewpage.action?pageId=49451791#CommonProblems-BuildfailsorbehavesdifferentlyinTeamCitybutnotlocally on a list of common issues that cause the behaviour difference)

Hi Fedor,

thanks for your quick reply. Unfortunately this issue is not related to discrepancies in .DotSettings. There are several reasons why this can't be the sole issue here:

- I tried to provoke a real Invalid Section error of the same category in the same file where a false positive "Unknown Razor section" error is marked by TeamCity. Resharper detects the "real" invalid section, and does not complain about the valid section where Teamcity was complaining. If "Unknown Razor section" errors were disabled or if the file in question was excluded from inspection in Visual Studio, then Resharper would not be able to detect the invalid section. 

- Just to make sure,  still had a look at the excluded files and excluded errors on my in my DotSettings (on all levels) on the dev machine. There is nothing that would prevent Resharper from finding the errors if there were any. 

- The errors metioned above are obvious false positives. For instance, every usage of System.String in one of my views is marked as "Error", so something is very wrong here. What's even more weird: When I open the same file in Visual Studio, I can sometime see the same "errors" in Resharper for a few seconds, but only until Resharper stops acting up and the "errors" magically disappear. So it seems to be some difference between the way Resharper and TeamCity are working in this regard. It would be interesting to know what exactly Resharper is doing until it figures out that these are not errors after all. 

Hello Adrian,

As there seems to be a ReSharper issue rather than TeamCity, could you please contact us via "Submit a request" form from this page https://resharper-support.jetbrains.com/hc/en-us/.

We'd be grateful if you could provide us some sample solution demonstrating the problem and dotSetttings files which you can export using ReSharper UI (ReSharper | Manage Options | right-click on each layer | Export to file).

Thank you.

Angelina,

I'm sorry, but there seems to be a misunderstanding. This is clearly a TeamCity Issue. Resharper does not show false positives, but Teamcity shows hundreds of them. Please advise on how to fix or work around this Teamcity issue.

Thanks,

Adrian

Hello Adrian,

TeamCity uses ReSharper Command Line Tools, specifically inspectcode tool in this case.

So we need to investigate what causes the difference in results between ReSharper in VS and ReShaper command line tool.

The requested information will be very helpful.

Thank you.

I'm seeing the same thing. Resharper in Visual Studio is showing all green, yet when I run the inspectcode command line tool I get warnings about possible NullReferenceException. We were hoping to rely on this tool to enforce coding standards in our CI pipeline.

So i just created a clean Asp.Net Core 3.1 project and added the follwing code to startup:

```

public void ConfigureServices(IServiceCollection services)
{
var ex = new Exception("blah");
var stackTrace = ex.StackTrace.Split(new[] { " at" }, StringSplitOptions.None);
Console.WriteLine(stackTrace);
}

```

Resharper in Visual Studio is perfectly happy. The command-line tool does this:

```

~\source\repos\WebApplication9> dotnet jb inspectcode .\WebApplication9.sln --output=inspectcode-report.xml --format=Xml --severity=WARNING
JetBrains Inspect Code 2020.2.4
Running in 64-bit mode, .NET runtime 3.1.9 under Microsoft Windows NT 10.0.16299.0
Using toolset version 16.0 from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin"
Configuration: Debug, Platform: Any CPU
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Warning: Can't fins parent during deserializing
Analyzing files

Analyzing Startup.cs
Analyzing WebApplication9.csproj
Inspecting launchSettings.json
Inspecting Startup.cs
Inspecting Program.cs
Inspecting appsettings.Development.json
Inspecting appsettings.json
Inspection report was written to ~\source\repos\WebApplication9\inspectcode-report.xml
~\source\repos\WebApplication9> cat .\inspectcode-report.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- Generated by JetBrains Inspect Code 2020.2.4 -->
<Report ToolsVersion="202.0.20200928.101108">
<Information>
<Solution>WebApplication9.sln</Solution>
<InspectionScope>
<Element>Solution</Element>
</InspectionScope>
</Information>
<IssueTypes>
<IssueType Id="PossibleNullReferenceException" Category="Potential Code Quality Issues" CategoryId="CodeSmell" Description="Possible 'System.NullReferenceException'" Severity="WARNING" WikiUrl="https://www.jetbrains.com/resharperplatform/help?Keyword=PossibleNullReferenceException" />
</IssueTypes>
<Issues>
<Project Name="WebApplication9">
<Issue TypeId="PossibleNullReferenceException" File="WebApplication9\Startup.cs" Offset="653-666" Line="17" Message="Possible 'System.NullReferenceException'" />
</Project>
</Issues>
</Report>
~\source\repos\WebApplication9>

```

Does the same thing in a simple .Net Core 3.1 console app. Works fine in a clean .Net Core 2.2 console app.

Never mind. This turned out to be a mismatch between the version of the command-line tool and the version of the VS extension. After upgrading the extension to latest 2020.2.4, I get the warning in both places.

I'm having the same issue with version 2022.04 on premises

Same project was working on 2019 version

I'm using the right R# configuration on inspection step (FiPlanSuite.sln.DotSettings). It seems also that the inspection step uses it. This is the build log
===========================

===========================

But I can't see it in teamcity-agent.log. Is this a normal behaviour?
This is the interesting part of teamcity-agent.log
==========================
[2022-06-06 17:11:54,408]   INFO - erStages.start.CallRunnerStage - ----------------------------------------- [ Step 4/4: 'Resharper inspection (Inspections (ReSharper))' (dotnet-tools-inspectcode), Build "FiPlanSuite / Quality tests" #516 {id=6485, buildTypeId='FiPlanSuite_QualityTests'} ] -----------------------------------------
[2022-06-06 17:11:54,424]   INFO - GenericCommandLineBuildProcess - Starting "C:\TeamCity\buildAgent\tools\jetbrains.resharper-clt.bundled\tools\inspectcode.exe --config=C:\TeamCity\buildAgent\temp\agentTmp\dotnet_tools_inspectcode.config "--no-swea --severity=WARNING"" in directory "C:\TeamCity\buildAgent\work\552cf102819b03b9"
[2022-06-06 17:11:54,424]   INFO - nner2.OsProcessHandlerListener - C:\TeamCity\buildAgent\tools\jetbrains.resharper-clt.bundled\tools\inspectcode.exe --config=C:\TeamCity\buildAgent\temp\agentTmp\dotnet_tools_inspectcode.config "--no-swea --severity=WARNING"
[2022-06-06 17:11:56,359]   INFO -    jetbrains.buildServer.AGENT - Updating agent parameters on the server: AgentDetails{Name='4planning', AgentId=1, BuildId=6485, AgentOwnAddress='null', AlternativeAddresses=[], Port=9090, Version='108575', PluginsVersion='108575-md5-5aad0f37c07f614357a0cb5f10f19ca2', AvailableRunners=[Ant, cargo-deploy-runner, csharpScript, dotnet, dotnet-tools-dupfinder, dotnet-tools-inspectcode, Duplicator, ftp-deploy-runner, FxCop, gradle-runner, Inspection, jb.nuget.installer, jb.nuget.pack, jb.nuget.publish, jetbrains.dotNetGenericRunner, jetbrains.mspec, jetbrains_powershell, jonnyzzz.grunt, jonnyzzz.node, jonnyzzz.npm, jonnyzzz.nvm, jonnyzzz.phantom, JPS, kotlinScript, Maven2, MSBuild, NAnt, nodejs-runner, NUnit, python-runner, Qodana, rake-runner, SBT, simpleRunner, sln2003, smb-deploy-runner, sonar-plugin, sonar-qube-msbuild, sonar-qube-msbuild-finish, ssh-deploy-runner, ssh-exec-runner, VisualStudioTest, VS.Solution], AvailableVcs=[tfs, jetbrains.git, mercurial, svn, perforce], AuthorizationToken='13efe9331d638360097d2cabd873d46c', PingCode='lCv1huyNDwUOFm2ocQu5HYEu0lG9rN0x'}
[2022-06-06 17:50:33,874]   INFO - nner2.OsProcessHandlerListener - Process exited with code 0. Command line: C:\TeamCity\buildAgent\tools\jetbrains.resharper-clt.bundled\tools\inspectcode.exe --config=C:\TeamCity\buildAgent\temp\agentTmp\dotnet_tools_inspectcode.config "--no-swea --severity=WARNING"
===============================

I try to change the R# inspector on server from 2020.2.4 (the same I was using un development machine) to the bundled (2021.1.2) but it did not help.

I can't restore old teamcity because an email issue related to TLS 1.2 (my provider, since June, supports only TLS 1.2)
Please help...

I think the issue is related to specifing parameters for inspectcode.exe

I'm specifing --no-swea --severity=WARNING

When I run inspectcode from inside TeamCity, the command line seems to be
inspectcode.exe --config=C:\TeamCity\buildAgent\temp\agentTmp\dotnet_tools_inspectcode.config "--no-swea --severity=WARNING"
Note the double quotes

Using the double quotes it seems that inspectcode ignores severity=WARNING because the generated xml file is full of messages

If I run the same statement from command line without double quotes the xml file contains the right messages (same as R# on Visual Studio)

In configuration I did not insert any double quotes. Is there a way to specify severity and no-swea without using parameters?

EDIT

Now parameters must be separated by new lines otherwise TC insert double quotes and inspectcode does not work properly