Team System 2010: Static Code Analysis, easier to set rules

terje — Sun, 12 Jul 2009 16:41:01 GMT

In Visual Studio the settings for static analysis is done on the project property page, a tab called Code Analysis. You can set which code analysis rules you want to be active. The default in Visual Studio 2008 is to use all. If you run with this default setting you will generate a lot of "noise", since there are a large set of rules. You need to create a set containing the rules you and your team find are suitable for your organization and project. This set you have to apply to every C# project in your solution. In Visual Studio 2008 there is no easy way to do this. At Osiris we made an Addin to Visual Studio to ease this. We defined the set in a separate file, and used the Addin to apply that to all projects in a solution.

With Visual Studio 2010 this will be more easy, because in 2010 you can define sets of rules. It comes with a default list of sets. You can also define your own sets, based on any of the others.

To make your own rule set, just open any of the default ones, make any changes you like to it, and save it under a suitable name. A rule set file is created, which can be checked in together with the other files of the project. This file [rule set] can now be used by any other project you have. So you only need to define it once.

You still have to select it for all the projects in the solution, but this has been made easier by having solution properties, where Code Analysis is one of these setting pages:

It's then easy to select the rule set you want for all projects within your solution.

Hiding generated code from Code Analysis, Metrics and Test Coverage

terje — Mon, 10 Nov 2008 09:09:41 GMT

When I do either Code Analysis, Code Metrics or looking at Code Coverage results, I don't want to have any generated code affecting the results. It just confuses the numbers, and I do not really care how generated code looks - it should just be invisible.

Generated code appears several places, code is generated by any of the multitude of wizards and designers in Visual Studio, or it may be generated by a 3rd part tool or generated by a self-written tool.

There exist an attribute which, if attached to the class or method, is intended to hide the code from these analyses. However, it fails to do so for the Code Coverage. The attribute is the GeneratedCodeAttribute, and it is intended to be used for any tools generated code. See http://blogs.msdn.com/fxcop/archive/2007/04/27/correct-usage-of-the-compilergeneratedattribute-and-the-generatedcodeattribute.aspx for more information on the correct usage. It can be used both at class level and method level.

However, the Code Coverage doesn't abide by these rules, as also reported in a two bug reports http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=338895 and http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=349243. The latter indicate they will not fix this bug, so please go in a vote for a fix!

As a workaround there are two more attributes which can be used, the DebuggerNonUserCode and DebuggerHidden attributes. The former is a combination of the latter and the DebuggerStepThrough attribute. The DebuggerNonUserCode attribute can be used on both class and method level.

By using this attribute in addition on generated code, it will not show up in the Code Coverage either.

The table below summarizes this:

	GeneratedCodeAttribute	DebuggerNonUserCode DebuggerHidden
Code Metrics	Excludes code	No Effect
Code Analysis	Excludes code	No Effect
Code Coverage	No Effect	Excludes code

Further, Microsoft seems to have "forgotten" to add these attributes to some of their own generated code, among them is the Winform generated code. The MSDataSetGenerator adds the GeneratedCode attrbute, but not the DebuggerNonUserCode attribute. (If the Code Coverage had abided by the rules, this would not have been a problem)

For Winform generated code, it is safe to add these attributes afterwards. The generated file will not be rewritten, just changed, when you add more or edit the controls. Just add them as shown below:

        [DebuggerNonUserCode]
        [GeneratedCode("Winform Designer","VS2008 SP1")]
        private void InitializeComponent()

The MSDataSetGenerator is not so forgiving, since the file easily can be rewritten. However, all the classes are partial, so by adding another manual file, and using the attributes there, most of the DataSet can be removed from the Code Coverage. Adding one dataset with one table generates a lot of classes, the code below shows what is needed to eliminate a dataset and its tableadapter for a table named ErrorLog.

namespace WindowsFormsApplication10

    [DebuggerNonUserCode]

    public partial class DataSet1

        [DebuggerNonUserCode]

        public partial class ErrorLogDataTable

        [DebuggerNonUserCode]

        public partial class ErrorLogRow

    namespace DataSet1TableAdapters

        [DebuggerNonUserCode]

        public partial class ErrorLogTableAdapter

        [DebuggerNonUserCode]

        public partial class TableAdapterManager

In my little test case, code coverage changed from 2,54% to 10% just by removing the DataSet1 alone.

Under the Properties folder (for a WinForm app), the Resources class is decorated with both attributes (Hurrah!) (luckily since it's not partial....) whereas the Settings class only have the GeneratedCode attribute. (Why are these two different ?). The Settings.Designer.cs file is regenerated each time you change anything in the settings designer, but it is partial, so the same trick as above with the DataSet can be used - create a new file, with the same partial class declaration, and add the DebuggerNonUserCode to it.

In a later post I'll try to make an even more comprehensive list of which generators work and which doesn't, in this respect, and outline the workarounds for these.

Hopefully - all of these will be fixed in Visual Studio 2010.