Extending code analysis in C#

Creator Denso QR Bar Code in C# Extending code analysis

If you run the MSBuild project using this task, you ll get a detailed NDepend report in the NDependOut folder. Let s try to integrate it with TeamCity. You ll integrate the NDepend report only for pure informational purposes. You haven t yet defined any build-breaking rules in the NDepend project file. The perfect place to show the analysis report is on the project page, not on the build page. You re getting the HTML report, so you re ready to integrate it with TeamCity. First, you have to define new artifacts on the General Settings page (see section 5.3.1 to learn how to do this). You can go with NDependOut/*.* => NDependOut.

rules so important that they must break the build so the CI process will stop and inform the team that something is wrong. To define the build-breaking rule in NDepend, you have to decorate it with the Critical Rule attribute. To do so, go to the CQL Query Editor and click the X button. TeamCity takes all the files from the NDependOut folder and copies them to the samenamed NDependOut folder as artifacts. Remember that each and every build will contain the data; this can result in a lot of files if you do the analysis continuously. Consider choosing only the files you need or running NDepend in the nightly build. In TeamCity, you can add custom reports at the server level to make them visible for the build in any project, or you can do it at the project level where they re visible only in a particular project. Figure 8.19 shows the second approach. To reach this dialog box, select Administration on the main TeamCity page, edit the project properties, and add a new tab on the Report Tabs page (see section 5.3.1 to learn how to do this).

Figure 8.19 Adding a new project-level tab in TeamCity. It contains the NDepend report from the last successful build.

From now on, the project page will always include the last NDepend report from the last successful build (see figure 8.20). NDepend integrates just as easily with other CI servers like CCNet. If you re using this server, you ll have to merge the results of the analysis with the Dashboard using the provided XSL transformation file. Extending the NDepend rules is easy due to the handy CQL. You don t have to write any NDepend extensions to enforce your own rules; but if you want to, you can do this in the commercial version of NDepend. One of the example CQL rules says that the number of lines in the method shouldn t be greater than 30. The query that checks this rule looks like this:

If you don t like the number, you can easily change it. Open Visual NDepend, and choose Reset Views to Work with CQL Language. In the CQL list, choose Methods Too Big, edit CQL, and change NbLinesOfCode > 30 to something bigger. That s it! If you re using TeamCity, you can do one more useful code analysis: you can check where the code is duplicated in your projects.

TeamCity includes the JetBrains Duplicates Finder for .NET. Its purpose is to find the places in your code where your team has duplicated the code. These places are obvious candidates for refactoring. Having too much duplicated code in the project can be dangerous: a bug in one piece of code may exist somewhere else in the code base, but you can t detect it if you don t check for code duplication. The Duplicates Finder is a separate build runner in TeamCity. You can reuse the existing project and define an additional build configuration to quickly get TeamCity to analyze your code for duplications. To do this, you can reuse some of an existing project s settings. Go to Administration, and, in the project, choose Create Build Configuration. Name the build configuration for example, CiDotNet Duplication Finder. You can reuse the existing version control system configuration you created earlier. In the build-runner configuration, choose Duplicates Finder (.NET). If you choose CI Trigger for the build configuration, you ll always get the duplication analysis. Figure 8.21 shows an example. Finding similar code fragments is one of the TeamCity features we recommend you use in a continuous manner. The more you reuse your code, the better. Code duplications aren t desirable. Analyze, detect, and get rid of them!