Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17548

FxCop results not being displayed for non-source files

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • violations-plugin
    • Windows Server 2008 R2 Enterprise, Jenkins 1.510, Violations plugin 0.7.11

      If a violation is found (by FxCop) for which there is no source code (such as a DLL), the Violations plugin does not display the actual violation message (just blank page with a red triangle with an "!" in it).

      This appears to be due to the plugin only displaying the "popup-message" for the errors when the user mouses-over the warning in the code view.

      However, if there is no code to view, there is no method to display the violations. Also, the violation "message" section is not displayed in either case (it needs to be as it contains valuable information).

      More Info

      Specifying FxCop output (XML) file in the Violations plugin will cause the Violation plugin to parse the (FxCop) XML file(s) generating violation (XML) files for each file (each of these XML files can contain multiple violations). These (Violation plugin) XML files are stored in the "~\jobs\<jenkins_job_name>\builds\<build_date_&_time>\violations\file" folder with ".xml" appended to the original file name (e.g.: domain.interface.dll -> domain.interface.dll.xml). When the user clicks on a source file (within the Violations plugin results page, the Violations XML file is parsed and displayed on the screen.)

      Each of these (Violations plugin) XML files contain a "file", (multiple) "violation", "line" and "type" sections.

      File Section

      The "file" section (of the XML file) contains the file "name", "last-modified" date, and a link to the "file" (if applicable):

      <file name="Server/Project.Server/Project.Domain.Model/ImageMetaData.cs"
      last-modified="1365521927609" file="c:\Jenkins\workspace\Project_Server_FxCop\Server\Projecty.Server\Project.Domain.Model\ImageMetaData.cs"
      >

      Violations

      The "violations" section contain the "line", violation "source", violation "severity", violation "type", violation "message", violation "severity-level", and the violation "popup-message":

      <violation
      line="82"
      source="Naming#CA1702"
      severity="Medium High"
      type="fxcop"
      message="<a href="http://msdn.microsoft.com/library/bb264474(VS.100).aspx">CompoundWordsShouldBeCasedCorrectly</a> - In member 'ImageMetaData.IsMetaDataEqual(ImageMetaData)', the compound word 'MetaData' in parameter name 'imageMetaData' exists as a discrete term. If your usage is intended to be single word, case it as 'Metadata' or strip the first token entirely if it represents any sort of Hungarian notation."
      severity-level="1"
      popup-message="Avoid creating compound words from terms which exist in the dictionary as discrete terms. Do not create a compound word such as 'StopWatch' or 'PopUp'. These terms are recognized in the dictionary and should be cased as 'Stopwatch' and 'Popup'."
      />

      Line Number

      Next, the Violations XML file contains a section containing zero or multiple "line number" entries which contain code from the source file.

      <line number='81'> public virtual bool IsMetaDataEqual(ImageMetaData imageMetaData)</line>
      <line number='82'> {</line>
      <line number='83'> if (Hash == imageMetaData.Hash &&</line>
      <line number='84'> Type == imageMetaData.Type &&</line>
      <line number='85'> FileLength == imageMetaData.FileLength</line>
      <line number='86'> )</line>
      <line number='87'> {</line>

      Type

      Finally, the "type" section indicates that it is "fxcop" and also contains the total number of violations found:

      <type type='fxcop' number='2' suppressed='0'/>

      If the file does not contain code, then all the violation line numbers are set to 0 (zero) and there is no "line number" section in the Violations plugin XML files. (See attached files: "ImageMetaData.cs.xml" and "Project.Domain.Model.Interfaces.IProjectStub.xml")

      The problem is two-fold: First if the file is not a source code file then no violations are displayed at all (see attached screenshot). Second, the "message" data is not displayed in either case (and in most cases contains more valuable information than the "popup-message").

      The Violations plugin should display a table of the "messages" and "popup-messages" if there is no code to display, and the "messages" text should be added to the pop-up table when there is code to display.

          [JENKINS-17548] FxCop results not being displayed for non-source files

          Ryan Davis added a comment -

          I'm experiencing something similar, here's my analysis.

          For me, FxCop generates messages at three levels: Namespace, Module (dll), Type, and Method. In the initial fxcop xml output, these are all all represented by <Message ...><Issue ...></Issue></Message> blocks, potentially inside <Namespace>, <Module>, <Type>, and <Method>, elements depending on what the message is.

          The <Issue> elements inside <Method> elements have Path, File, and Line attributes; for me these come through to the Violations plugin no problem. If I have something like:

          <Issue Certainty="95" Level="Error" Path="c:\Jenkins\workspace\proj\src\Core" File="Logging.cs" Line="20">Make 'LogFilterAttribute' sealed ...</Issue>

          Then the violations report will list src/Core/Logging.cs properly in the table, and I can click on it and see the issue on the right line as normal.

          The problem happens when the <Issue> doesn't have the file information. For me, this happens a lot:

           
          ...
          <Type Name="TestController" ...>
           <Members>
            <Member Name="#A" ...>
             <Messages>
              <Message>
               <Issue NO LINE INFO>
              </Message>
             </Members>
            </Member>
            <Member Name="#B" ...>
             <Messages>
              <Message>
               <Issue HAS LINE INFO>
              </Message>
             </Members>
            </Member>
           </Messages>
          </Type>
          

          In some cases, FxCop can't figure out where some code is, and if fxcop doesn't know, then the Violations plugin doesn't know.

          From http://blogs.msdn.com/b/codeanalysis/archive/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others.aspx:

          FxCop and Visual Studio Code Analysis both use the information stored in the Program Database (PDB) file to map members back to a particular source file. Unfortunately, because this file was orginally only designed for use by a debugger, it only contains information about actual executable code. This means that FxCop cannot find non-executable code such as namespaces, types, fields, interface methods and abstract methods.

          So the root problem here is that FxCop is reflecting on assemblies instead of parsing source code (like every other lint tool).

          That's the source of a lot of the "blank" pages; FxCop can't determine a source location, so it can't tell Violations. Also, some C# elements can't really have a source file... what would be the right source file for the warning about "don't put underscores in your namespace"?

          I think it's possible to apply some heuristics to find a reasonable source file, but that'd be on a warning-by-warning basis, and that's really FxCop's job.

          My best bet would be to modify the violations plugin to:

          1. show violations even when there is no source - just print a table of the violations if there's no file - change FileModelProxy.getFileContent to check if fileModel.getLines has any entries, and if not render a different table of just the violations.
          2. change the fxcop parser; when it sees file information, remember it for that type. In FxCopParser.parseIssue call something like model.getFileModel(parentName).setSourceFile(sourceFile) (with null checks). This would still fail for partial classes and namespaces, but would catch the most common cases.

          If I can get a java dev environment going and steal more time I'll try to get a couple of pull requests on github to cover these.

          Ryan Davis added a comment - I'm experiencing something similar, here's my analysis. For me, FxCop generates messages at three levels: Namespace, Module (dll), Type, and Method. In the initial fxcop xml output, these are all all represented by <Message ...><Issue ...></Issue></Message> blocks, potentially inside <Namespace> , <Module> , <Type> , and <Method> , elements depending on what the message is. The <Issue> elements inside <Method> elements have Path , File , and Line attributes; for me these come through to the Violations plugin no problem. If I have something like: <Issue Certainty="95" Level="Error" Path="c:\Jenkins\workspace\proj\src\Core" File="Logging.cs" Line="20">Make 'LogFilterAttribute' sealed ...</Issue> Then the violations report will list src/Core/Logging.cs properly in the table, and I can click on it and see the issue on the right line as normal. The problem happens when the <Issue> doesn't have the file information. For me, this happens a lot: ... <Type Name= "TestController" ...> <Members> <Member Name= "#A" ...> <Messages> <Message> <Issue NO LINE INFO> </Message> </Members> </Member> <Member Name= "#B" ...> <Messages> <Message> <Issue HAS LINE INFO> </Message> </Members> </Member> </Messages> </Type> In some cases, FxCop can't figure out where some code is, and if fxcop doesn't know, then the Violations plugin doesn't know. From http://blogs.msdn.com/b/codeanalysis/archive/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others.aspx: FxCop and Visual Studio Code Analysis both use the information stored in the Program Database (PDB) file to map members back to a particular source file. Unfortunately, because this file was orginally only designed for use by a debugger, it only contains information about actual executable code. This means that FxCop cannot find non-executable code such as namespaces, types, fields, interface methods and abstract methods. So the root problem here is that FxCop is reflecting on assemblies instead of parsing source code (like every other lint tool). That's the source of a lot of the "blank" pages; FxCop can't determine a source location, so it can't tell Violations. Also, some C# elements can't really have a source file... what would be the right source file for the warning about "don't put underscores in your namespace"? I think it's possible to apply some heuristics to find a reasonable source file, but that'd be on a warning-by-warning basis, and that's really FxCop's job. My best bet would be to modify the violations plugin to: show violations even when there is no source - just print a table of the violations if there's no file - change FileModelProxy.getFileContent to check if fileModel.getLines has any entries, and if not render a different table of just the violations. change the fxcop parser; when it sees file information, remember it for that type. In FxCopParser.parseIssue call something like model.getFileModel(parentName).setSourceFile(sourceFile) (with null checks). This would still fail for partial classes and namespaces, but would catch the most common cases. If I can get a java dev environment going and steal more time I'll try to get a couple of pull requests on github to cover these.

          Ryan Davis added a comment -

          I forked the code and got the violations being displayed. I looked into changing FxCopParser.parseIssue, but that's a rabbit-hole for another day.

          Code: https://github.com/AccelerationNet/violations-plugin/tree/JENKINS-17548

          Pull request: https://github.com/jenkinsci/violations-plugin/pull/33

          Binary you can upload to jenkins: https://github.com/AccelerationNet/violations-plugin/releases/tag/violations-0.7.15+JENKINS-17548

          Ryan Davis added a comment - I forked the code and got the violations being displayed. I looked into changing FxCopParser.parseIssue , but that's a rabbit-hole for another day. Code: https://github.com/AccelerationNet/violations-plugin/tree/JENKINS-17548 Pull request: https://github.com/jenkinsci/violations-plugin/pull/33 Binary you can upload to jenkins: https://github.com/AccelerationNet/violations-plugin/releases/tag/violations-0.7.15+JENKINS-17548

          Code changed in jenkins
          User: Mirko Friedenhagen
          Path:
          src/main/java/hudson/plugins/violations/render/FileModelProxy.java
          src/main/resources/hudson/plugins/violations/render/FileModelProxy/index.jelly
          src/main/webapp/css/style.css
          http://jenkins-ci.org/commit/violations-plugin/f055396f299498635839597fe12f338192414511
          Log:
          Merge pull request #33 from AccelerationNet/JENKINS-17548

          display violations when no source file is present

          Compare: https://github.com/jenkinsci/violations-plugin/compare/0493faaff136...f055396f2994

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mirko Friedenhagen Path: src/main/java/hudson/plugins/violations/render/FileModelProxy.java src/main/resources/hudson/plugins/violations/render/FileModelProxy/index.jelly src/main/webapp/css/style.css http://jenkins-ci.org/commit/violations-plugin/f055396f299498635839597fe12f338192414511 Log: Merge pull request #33 from AccelerationNet/ JENKINS-17548 display violations when no source file is present Compare: https://github.com/jenkinsci/violations-plugin/compare/0493faaff136...f055396f2994

          Mark Waite added a comment -

          The violations plugin is deprecated. It has an unresolved security vulnerability. The last commit to the source code repository was over 7 years ago. Closing the issue as "Won't fix"

          Mark Waite added a comment - The violations plugin is deprecated. It has an unresolved security vulnerability. The last commit to the source code repository was over 7 years ago. Closing the issue as "Won't fix"

            peterkittreilly peterkittreilly
            jeff_hughes Jeff Hughes
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: