C# plugin 5.2 fxcop issues don't show source + show issues that were previous marked as false-positive

[joni.pu...@tieto.com]

Hi,

I installed the C# plugin 5.2 and ran few analysis. We have quite many FxCop rules activated in quality profile and those have been working correctly before. Now after updating the plugin we got "new" issues on all projects. The issues don't have source available if clicked on the issue/finding (path is only to the cs project/dll?). Most (if not all) of these were actually marked as false-positive previously. This is very annoying and looks like a bug. At least the source code should be visible in the issue. In some cases the class file path was added in the finding/issue description and the path was the temporary path of the file from the server where the analysis was performed.

Also one of the new imported rules from SonarLint has incorrect name, I believe it was S2201.

This happened on two separate server installations.

I reverted back to C# plugin 5.1 and now analysis works like it should.

[David]

Hi,

We also have this problem and had to revert to 5.1 today.  The issues bunch up and no source code is shown.  It certainly does seem like a bug.

The issue appeared when using the Sonar Scanner with VS Bootstrapper, but not the MSBuild Scanner.  We are still transitioning many projects given the differences in results between the two and so can't drop the sonar scanner yet.

Technical Debt figures also tripled but the issues were roughly the same even when looking across the various severities.  Notable rules that appeared in large numbers were CA1709, CA1030 where they did not before.

David

[Tamas Vajk]

Hello,

We have changed the FxCop reporting in version 5.2. Before the analysis was silently ignoring some issues, and with 5.2 these issues are showing up. Specifically, these tickets seem to be related to the behavior you are experiencing:

https://jira.sonarsource.com/browse/SONARFXCOP-32

https://jira.sonarsource.com/browse/SONARFXCOP-45

https://jira.sonarsource.com/browse/SONARFXCOP-34

As for the title of S2201, we recognized this bug too late in the release process, so the issue is (going to be) fixed in version 5.3 of the C# plugin.

Regards,

Tamas

Tamas VAJK | SonarSource
Language Team

http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/521936f1-7fcc-4c39-9b8f-b73f61dd8526%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[tgt...@gmail.com]

We also have this problem.

It's not only that previously ignored issues are now visible because of the bug fix, the problem is worse:
For us it seems that all FxCop rules that apply to certain lines of code, are now also shown on the assembly level.

An example is the rule: CA1822: Mark members as static.

This rule always worked and showed up correctly in SonarQube but now it is also listed as an assembly issue. If you click on it, you don't go to the actual file, so it's quite useless.

As a consequence of this behaviour I had to deactivate allmost all FxCop rules in our quality profile.

I really hope this problem can be fixed. It's good that SonarQube can now support FxCop rules that don't apply to a certain file, but to an assembly, but it seems like all FxCop rules have been impacted and behave strangely now.

[David]

Hello,

We have found this to be caused by not taking correct note of the compatible plugins.  So the C# 5.2 plugin can only be used with the MSBuild runner, not the sonar runner. If used with the sonar runner everything goes nuts.  Reverting back to C# plugin 5.1 was OK with the sonar runner for us (although that is not officially compatible, we were loath to risk going back any further) .  Similarly on another server, using the C# 5.2 plugin with the MSBuild Runner there was no sign of the problem.

David

[tgt...@gmail.com]

Hi David,

In our case we are using the latest MSBuild Runner (2.0). The problem is there for us.

[joni.pu...@gmail.com]

Updated to C# plugin 5.3 and MSBuild.SonarQube.Runner-2.1 with SonarQube 5.6. Still getting these fxcop issues with no source code shown on the issue. 

[David]

Hi,

You are quite correct.  In fact we have now found this on our test instance of SQ 5.4 and C#5.2 with the msbuild 2.0 runner when we began to look seriously again at migrating.  It is everywhere and a really bad bug.

The file does not display any code and the issues are all listed at the top of the file.  Even the layout is screwed up, no longer full width - perhaps this is a css bug? 

This really needs urgent attention and additional functional testing because at present it renders C# analysis pretty useless. 

David

[David]

Hello,

Further to this.  It may be related to the handling of the exclusions list.

Files that are excluded  by wildcard e.g. **/*word*  are (correctly) not listed in the Code section, however their issues and files are shown in the Issues section. e.g. when filtering by rule files are shown that should be excluded. Clicking through to the issues in the file raises the fault. Exclusions are made by the required tag within source csproj files. 

Files that are not excluded don't seem to show the same problem in the Issues View, their issues and code are shown correctly.

As mentioned, the problem does not occur using the C# 5.1 plugin when using the VS Bootstrapper in a separate environment analysing the same code and versions.

Regards,

David

[tgt...@gmail.com]

Just upgraded to C# 5.3 and MSBuild SonarQube Scanner 2.1 and the problem is still there.

Indeed it seems like that for excluded files, or issues flagged as false positive / won't fix on file level, that they are shown on assembly level.

If the problem cannot be solved easily, I would suggest the C# team to remove support for FxCop rules for assemblies and to restore the old behaviour. Because the current behaviour is much worse! Every time I have to tell my team members why they get unexpected issues showing up for their changes and it's getting quite annoying now.

[tgt...@gmail.com]

Could you perhaps confirm the behaviour described in this thread or turn it into a bug report? C# plugin 5.3 did not solve the issues.

The old behaviour (which ignored violations on assemblies) is at least better than the current behaviour, because it generates a lot of noise.


Op vrijdag 3 juni 2016 11:04:18 UTC+2 schreef Tamas Vajk:

[Tamas Vajk]

Hello Guys,

I tried to reproduce the issue mentioned above with CA1822 not being shown on a line. My test setup was SQ5.3, C# plugin 5.3, Scanner for MsBuild 2.0 and the issue shows up correctly on the line.

Could you guys try to repro the issue on a minimal code sample that can possibly be shared with us if the issue persists? 

Also, when you run the Scanner for MsBuild, it creates a .sonarqube folder next to your solution. In the out folder there are project specific subfolders. Each of them should contain a ProjectInfo.xml with <AnalysisResult Id="FxCop" Location=... XML entry. Please have a look at the referenced file, and see the content. On my side, I see a Message entry with CheckId="CA1822", and inside the Issue has a File, and Line location. Could you check if you find entries in the FxCop report that have proper location, and still do not show up on SQ as line based issues? https://jira.sonarsource.com/browse/SONARFXCOP-32 lists a couple of such issues, however CA1822 should show up on a line, so what you're experiencing is bug, but I can't reproduce it yet.

Thanks,

Tamas

[tgt...@gmail.com]

The picture below shows an example.
CA1822 is triggered for two properties and the method SetDefaultAsync.
However, it should also be shown for method RetrieveDefaultAsync, but it's not. Instead, that error is shown on the assembly level. I looked in the ProjectInfo.xml and there I see that the line number is missing for RetrieveDefaultAsync:

      <Namespace Name="Domain.Defaults">
       <Types>
        <Type Name="StatusDefault" Kind="Class" Accessibility="Public" ExternallyVisible="True">
         <Members>
          <Member Name="#EntityName" Kind="Property" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="MarkMembersAsStatic" Category="Microsoft.Performance" CheckId="CA1822" Status="Active" Created="2016-06-27 13:51:45Z" FixCategory="DependsOnFix">
             <Issue Certainty="95" Level="Warning" Path="C:\Jenkins\workspace\master\src\Domain\Defaults" File="StatusDefault.cs" Line="9">The 'this' parameter (or 'Me' in Visual Basic) of 'StatusDefault.EntityName' is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#PropertyName" Kind="Property" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="MarkMembersAsStatic" Category="Microsoft.Performance" CheckId="CA1822" Status="Active" Created="2016-06-27 13:51:45Z" FixCategory="DependsOnFix">
             <Issue Certainty="95" Level="Warning" Path="C:\Jenkins\workspace\master\src\Domain\Defaults" File="StatusDefault.cs" Line="10">The 'this' parameter (or 'Me' in Visual Basic) of 'StatusDefault.PropertyName' is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#RetrieveDefaultAsync`1(!!0)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="MarkMembersAsStatic" Category="Microsoft.Performance" CheckId="CA1822" Status="Active" Created="2016-06-27 13:51:45Z" FixCategory="DependsOnFix">
             <Issue Certainty="95" Level="Warning">The 'this' parameter (or 'Me' in Visual Basic) of 'StatusDefault.RetrieveDefaultAsync&lt;TEntity&gt;(TEntity)' is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#SetDefaultsAsync`1(!!0)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="MarkMembersAsStatic" Category="Microsoft.Performance" CheckId="CA1822" Status="Active" Created="2016-06-27 13:51:45Z" FixCategory="DependsOnFix">
             <Issue Certainty="95" Level="Warning" Path="C:\Jenkins\workspace\master\src\Domain\Defaults" File="StatusDefault.cs" Line="19">The 'this' parameter (or 'Me' in Visual Basic) of 'StatusDefault.SetDefaultsAsync&lt;TEntity&gt;(TEntity)' is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.</Issue>
            </Message>
           </Messages>
          </Member>
         </Members>
        </Type>
       </Types>
      </Namespace>

Op maandag 27 juni 2016 10:37:11 UTC+2 schreef Tamas Vajk:

[Tamas Vajk]

Hi,

This seems like an FxCop problem. Can you verify that this happens for all async methods? FxCop works on the compiled assembly, and for async the compiler generates the underlying state machine. I suspect that FxCop is not able to map back the reported method to the proper location.

Regards,

Tamas

[joni.pu...@gmail.com]

Hi

I updated Sonar to 6.0 and C# plugin to 5.3.2 and ran few analysis again. I use the SonarQube Scanner for MSBuild 2.1. The issues on assembly level are still visible (no reference to code files).

As suggested by  Tamas I looked into the ProjectInfo.xml file and those ...CodeAnalysisLog.xml files.

I see that there are issues without a file/line reference, for example this:

<Issue Name="Member" Certainty="95" Level="Error">Rename virtual/interface member 'IConnectionProvider.Get()' so that it no longer conflicts with the reserved language keyword 'Get'. Using a reserved keyword as the name of a virtual/interface member makes it harder for consumers in other languages to override/implement the member.</Issue>

This issue is shown in the Sonar web UI without any reference to a file.

I then reverted the C# plugin to 5.1 and ran analysis again. The same issues without file/line references are in the ..CodeAnalysisLog.xml files but these are not visible in the web UI. 

So yeah this is not a bug: those issues were just silently ignored before? :) Some of these are almost same as reported by the SonarLint which do have file/line shown in the web UI so my initial though was that duplicate/previously false positives are popping up with never c# plugins... But this is quite annoying since some of these findings are quite exact, like this one with using a reserved word. Why isnt a file reference provided by fxcop, silly... This one is of course easy to find with IDE and fix it but some issues have more generic message of the issue and are harder to find and fix.

The ...CodeAnalysisLog.xml file also has a namespace, type name and kind reported for issues but these are not visible in the UI. This would be valuable info for our developers for finding the actual cause of the issue that do not have file/line references.

So my plan is to update for the newest plugin and review the findings that are reported on the assembly level. I will only leave most critical ones of these activated. However is there a handy list anywhere where such issues are listed that are only reported on the assembly level without file/line reference?

Br

[joni.pu...@gmail.com]

Ran few more tests and noticed that actually some fxcop issues are actually reported with file/line reference while some are not.

Here's what I've discovered so far:

- async method will not have a file reference

- if the method is defined in interface, issue will not have a file reference. It will not generate another issue for the implementation though.

System setup:

- SonarQube 6.0

- C# plugin 5.3.2

- SonarQube Scanner for MSBuild 2.1

- MsBuild  Build Engine version 14.0.25123.0

Analysis was run with following commands:

MSBuild.SonarQube.Runner.exe begin /k:TESTKEY /n:ExampleLibrary.sln /v:"versionX" 

msbuild ExampleLibrary.sln /p:Configuration=Debug /p:Platform="Any CPU" /m:8 /nr:false /fl1 /fl2

MSBuild.SonarQube.Runner.exe end

Here's the poc code:

 

public class Class1 : ISilly
   {
        public void AddStuff(int id, List<int> list)
        {
            list.Add(id);
        }

        public async Task AddStuffAsync(int id, List<int> list)
        {
            await Task.Run(() => { list.Add(id);});
        }

        public string GetStuff()
        {
            return "a property is better";
        }

        public async Task<string> GetStuffAsync()
        {
            var result = GetStuff();
            return await Task.FromResult(result);
        }

        public string GetStuffNotInInterface()
        {
            return "a property is better";
        }
    }

    public interface ISilly
    {
        void AddStuff(int id, List<int> list);
        Task AddStuffAsync(int id, List<int> list);
        string GetStuff();
        Task<string> GetStuffAsync();
    }
 

Heres the project's CodeAnalysisLog.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="c:\program files (x86)\microsoft visual studio 14.0\team tools\static analysis tools\fxcop\Xml\CodeAnalysisReport.xsl"?>
<FxCopReport Version="14.0">
 <Targets>
  <Target Name="D:\sonartest\ExampleLibrary\ExampleLibrary\bin\Debug\ExampleLibrary.dll">
   <Modules>
    <Module Name="examplelibrary.dll">
     <Namespaces>
      <Namespace Name="ExampleLibrary">
       <Types>
        <Type Name="Class1" Kind="Class" Accessibility="Public" ExternallyVisible="True">
         <Members>
          <Member Name="#AddStuff(System.Int32,System.Collections.Generic.List`1&lt;System.Int32&gt;)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="DoNotExposeGenericLists" Category="Microsoft.Design" CheckId="CA1002" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="95" Level="Error" Path="D:\sonartest\ExampleLibrary\ExampleLibrary" File="Class1.cs" Line="12">Change 'List&lt;int&gt;' in 'Class1.AddStuff(int, List&lt;int&gt;)' to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#AddStuffAsync(System.Int32,System.Collections.Generic.List`1&lt;System.Int32&gt;)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="DoNotExposeGenericLists" Category="Microsoft.Design" CheckId="CA1002" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="95" Level="Error">Change 'List&lt;int&gt;' in 'Class1.AddStuffAsync(int, List&lt;int&gt;)' to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#GetStuffNotInInterface()" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="UsePropertiesWhereAppropriate" Category="Microsoft.Design" CheckId="CA1024" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="50" Level="Warning" Path="D:\sonartest\ExampleLibrary\ExampleLibrary" File="Class1.cs" Line="35">Change 'Class1.GetStuffNotInInterface()' to a property if appropriate.</Issue>

            </Message>
           </Messages>
          </Member>
         </Members>
        </Type>

        <Type Name="ISilly" Kind="Interface" Accessibility="Public" ExternallyVisible="True">
         <Members>
          <Member Name="#AddStuff(System.Int32,System.Collections.Generic.List`1&lt;System.Int32&gt;)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="DoNotExposeGenericLists" Category="Microsoft.Design" CheckId="CA1002" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="95" Level="Error">Change 'List&lt;int&gt;' in 'ISilly.AddStuff(int, List&lt;int&gt;)' to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#AddStuffAsync(System.Int32,System.Collections.Generic.List`1&lt;System.Int32&gt;)" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="DoNotExposeGenericLists" Category="Microsoft.Design" CheckId="CA1002" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="95" Level="Error">Change 'List&lt;int&gt;' in 'ISilly.AddStuffAsync(int, List&lt;int&gt;)' to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#GetStuff()" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="UsePropertiesWhereAppropriate" Category="Microsoft.Design" CheckId="CA1024" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="50" Level="Warning">Change 'ISilly.GetStuff()' to a property if appropriate.</Issue>
            </Message>
           </Messages>
          </Member>
          <Member Name="#GetStuffAsync()" Kind="Method" Static="False" Accessibility="Public" ExternallyVisible="True">
           <Messages>
            <Message TypeName="UsePropertiesWhereAppropriate" Category="Microsoft.Design" CheckId="CA1024" Status="Active" Created="2016-08-10 08:39:19Z" FixCategory="Breaking">
             <Issue Certainty="50" Level="Warning">Change 'ISilly.GetStuffAsync()' to a property if appropriate.</Issue>

            </Message>
           </Messages>
          </Member>
         </Members>
        </Type>
       </Types>
      </Namespace>

     </Namespaces>
    </Module>
   </Modules>
  </Target>
 </Targets>
 <Rules>
  <Rule TypeName="DoNotExposeGenericLists" Category="Microsoft.Design" CheckId="CA1002">
   <Name>Do not expose generic lists</Name>
   <Description>Do not expose List&lt;T&gt; in object models. Use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt; instead. List&lt;T&gt; is meant to be used from implementation, not in object model API. List&lt;T&gt; is optimized for performance at the cost of long term versioning. For example, if you return List&lt;T&gt; to the client code, you will not ever be able to receive notifications when client code modifies the collection.</Description>
   <Resolution Name="Default">Change {0} in {1} to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;</Resolution>
   <Owner />
   <Url>http://msdn.microsoft.com/library/ms182142.aspx</Url>
   <Email>[none]</Email>
   <MessageLevel Certainty="95">Error</MessageLevel>
   <File Name="designrules.dll" Version="14.0.0.0" />
  </Rule>
  <Rule TypeName="UsePropertiesWhereAppropriate" Category="Microsoft.Design" CheckId="CA1024">
   <Name>Use properties where appropriate</Name>
   <Description>Properties should be used instead of Get/Set methods in most situations. Methods are preferable to properties in the following situations: the operation is a conversion, is expensive or has an observable side-effect; the order of execution is important; calling the member twice in succession creates different results; a member is static but returns a mutable value; or the member returns an array.</Description>
   <Resolution Name="Default">Change {0} to a property if appropriate.</Resolution>
   <Owner />
   <Url>http://msdn.microsoft.com/library/ms182181.aspx</Url>
   <Email>[none]</Email>
   <MessageLevel Certainty="75">Warning</MessageLevel>
   <File Name="designrules.dll" Version="14.0.0.0" />
  </Rule>
 </Rules>
 <Localized>
  <String Key="Category">Category</String>
  <String Key="Certainty">Certainty</String>
  <String Key="CollapseAll">Collapse All</String>
  <String Key="CheckId">Check Id</String>
  <String Key="Error">Error</String>
  <String Key="Errors">error(s)</String>
  <String Key="ExpandAll">Expand All</String>
  <String Key="Help">Help</String>
  <String Key="Line">Line</String>
  <String Key="Messages">message(s)</String>
  <String Key="LocationNotStoredInPdb">[Location not stored in Pdb]</String>
  <String Key="Project">Project</String>
  <String Key="Resolution">Resolution</String>
  <String Key="Rule">Rule</String>
  <String Key="RuleFile">Rule File</String>
  <String Key="RuleDescription">Rule Description</String>
  <String Key="Source">Source</String>
  <String Key="Status">Status</String>
  <String Key="Target">Target</String>
  <String Key="Warning">Warning</String>
  <String Key="Warnings">warning(s)</String>
  <String Key="ReportTitle">Code Analysis Report</String>
 </Localized>
</FxCopReport>

And screenshot from web UI

So simply disabling the fxcop rules does not help as I though previously. I will not be able to upgrade to newest C# plugin after all.

Looks like a fxcop bug...

[joni.pu...@gmail.com]

Interesting part is that if I run the Code Analysis from VS it displays the file/line. See image below

[joni.pu...@gmail.com]

The odd thing is that the CodeAnalysisLog.xml file that is generated when running the code analysis from IDE looks exactly the same as via msbuild/sonar analysis. Dunno where the IDE gets the line/class references.

[joni.pu...@gmail.com]

OK probably found the root cause for the behavior of not displaying the file/line:

https://blogs.msdn.microsoft.com/codeanalysis/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others/

The point 3 and the note. There is no way to get that information via fxcop even with the pdb info :(

So this being the case could there be an option to ignore/hide issues that don't have link to source file from Sonar web UI?

[Tamas Vajk]

Hello,

I think ignoring/hiding them would lead to confusion. When you run the analysis inside the IDE, you'd get N issues, while in SonarQube would get M. How come M != N? I think it's better to show all issues on SonarQube side. 

We discussed this problem internally, how the SQ UI should handle these issues. And concluded that issues without location are a corner case (as you said our rules have locations, and most of the FxCop ones too), so we are not going to introduce any special UI for these issues. 

Note, that you will only have to deal with these issues once. You confirm/reject/.. them, and then they won't show up again. So if you're tracking the introduced leak, then you'd deal with a bunch of these issues once when you introduce SQ, and then when you introduce some code that produces these kind of issues, but chances are in these incremental steps there are only a couple issues each time. Another option is to disable the noisy FxCop rules altogether. In this case you'd have to decide for yourself if they produce enough value to deal with the above inconvenience or not.

Tamas

Tamas VAJK | SonarSource
Language Team

http://sonarsource.com

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/c9ace3b4-0a9d-41dc-bb5e-7dcd052dea7b%40googlegroups.com.

[joni.pu...@gmail.com]

Hi,

Thanks for the reply!

After giving it some though I agree that hiding the issues without files is not a solution. These issues are correct and can be fixed. But it would be nice to somehow more easily filter these issues from the issues list. With that filter one could easily mark a group of issues as Wont fix. Also we might want to disable such rules that we just mark as wont fix in a batch... It is also bit confusing when one clicks on one of these issues and he is redirected to an empty page where the code file should be. Most of our developers thought that this is a bug. Some kind of a indication would be nice :)

The problem with our sonarqube projects is that we have quite large projects and use async-await programming model and and almost every class has an interface due to the DI pattern. Now given that (some) FxCop issues for async and interface methods don't have the file/line available I wouldn't call it just "a corner case." For example one bigger project gets around 400 new issues with the newer c# plugin. All valid without file/line reference.

SonarQube has been the main place to check for code quality issues. It is part of our build and we rarely if ever run code analysis from the IDE (except for the live issues that are displayed on the open files). We want to check all new issues/quality gate from sonar and updating to the newer plugin will generate a lot of "new findings" which is bit unfortunate. But on the other hand these issues arent new: they have existed all the time but they werent reported on the web UI :)

So what I'd hope is that there would be some kind of an indication that no source code is available for the issue when it is not available. Now it does look like a bug.

Br,

Joni

On Monday, August 15, 2016 at 3:20:06 PM UTC+3, Tamas Vajk wrote:

Hello,

I think ignoring/hiding them would lead to confusion. When you run the analysis inside the IDE, you'd get N issues, while in SonarQube would get M. How come M != N? I think it's better to show all issues on SonarQube side. 

We discussed this problem internally, how the SQ UI should handle these issues. And concluded that issues without location are a corner case (as you said our rules have locations, and most of the FxCop ones too), so we are not going to introduce any special UI for these issues. 

Note, that you will only have to deal with these issues once. You confirm/reject/.. them, and then they won't show up again. So if you're tracking the introduced leak, then you'd deal with a bunch of these issues once when you introduce SQ, and then when you introduce some code that produces these kind of issues, but chances are in these incremental steps there are only a couple issues each time. Another option is to disable the noisy FxCop rules altogether. In this case you'd have to decide for yourself if they produce enough value to deal with the above inconvenience or not.

Tamas

Tamas VAJK | SonarSource
Language Team

http://sonarsource.com

On 10 August 2016 at 11:48, <joni.pu...@gmail.com> wrote:

OK probably found the root cause for the behavior of not displaying the file/line:

https://blogs.msdn.microsoft.com/codeanalysis/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others/

The point 3 and the note. There is no way to get that information via fxcop even with the pdb info :(

So this being the case could there be an option to ignore/hide issues that don't have link to source file from Sonar web UI?

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

[David]

Hi,

I have to agree with Joni, calling this a corner case is really ignoring an elephant in the room.  The issue is so pervasive that it makes the latest sonarqube and plugins pretty unusable for .NET.  I suspect the test projects the guys at sonar are using are either very small, very out of date or pretty sanitised.  We could not use SQ in this state and reverted to an earlier version.

Opening page after page of code with issues stacked up, css rendering errors and missing code is just buggy and not something we can put in front of users.

David

On Monday, August 15, 2016 at 1:20:06 PM UTC+1, Tamas Vajk wrote:

Hello,

I think ignoring/hiding them would lead to confusion. When you run the analysis inside the IDE, you'd get N issues, while in SonarQube would get M. How come M != N? I think it's better to show all issues on SonarQube side. 

We discussed this problem internally, how the SQ UI should handle these issues. And concluded that issues without location are a corner case (as you said our rules have locations, and most of the FxCop ones too), so we are not going to introduce any special UI for these issues. 

Note, that you will only have to deal with these issues once. You confirm/reject/.. them, and then they won't show up again. So if you're tracking the introduced leak, then you'd deal with a bunch of these issues once when you introduce SQ, and then when you introduce some code that produces these kind of issues, but chances are in these incremental steps there are only a couple issues each time. Another option is to disable the noisy FxCop rules altogether. In this case you'd have to decide for yourself if they produce enough value to deal with the above inconvenience or not.

Tamas

Tamas VAJK | SonarSource
Language Team

http://sonarsource.com

On 10 August 2016 at 11:48, <joni.pu...@gmail.com> wrote:

OK probably found the root cause for the behavior of not displaying the file/line:

https://blogs.msdn.microsoft.com/codeanalysis/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others/

The point 3 and the note. There is no way to get that information via fxcop even with the pdb info :(

So this being the case could there be an option to ignore/hide issues that don't have link to source file from Sonar web UI?

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.