Currently no support of VS2012

Due to the fact that the current version of the Power Tool is not compatible to Visual Studio 2012, there won´t be an upgrade for the Code Metrics Viewer extension. There is a suggestion on Microsoft´s user voice portal to either open up the code metrics calculation interface, or to provide a new version of the commandline utility, that is not dependent on Visual Studio 2010. Using the following link you can vote for it: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3014740-please-update-visual-studio-metrics-power-tool-to

Update, 2013/01/7: I just used some time to play with the Roslyn CTP and created a tool that can calculate metrics from syntax trees and semantic models (in strict sense a replacement for the Power Tool, that does not act on IL, but on source code). By now, I can calculate the same metric results provided by the Power Tool for C# projects and I also added some new metrics.

Update, 2013/01/14: I started to make the extension available to Visual Studio 2012; I just ported the existing code base and removed everything related to Microsoft´s power tool, that can´t be used anymore. The tool-window get´s a complete make-over supporting both the dark- and light theme. Maybe I have to replace functionality which is dependent on Windows Forms by using WPF, but I don´t know yet. The toolbar is now a native toolbar, that fits much better into the selected theme. As long as Roslyn isn´t ready-to-market, this extension will be a CTP as well, that requires an existing installation of the Roslyn components.

Update, 2013/01/16: A first look at the new UI…

dark-theme-ui

Update, 2013/01/25: I worked alot on the user-interface… Instead of reusing the existing win-forms tree-listview implementation from the previous version , I decided to create a tree-listview using WPF. I am quite familiar with WPF, so I thought the hardest part of the entire project would be the implementation of the actual metric calculation functionality (which I have achieved within a couple of hours), but in the end I used more time to style the WPF listview (thanks a lot to a swedish friend of mine, who helped me to solve some very tricky issues and polish it). It was well worth investing the time, because the new control allows to scroll horizontally, the scrollbars are themed automatically, positioning of grid columns is now supported and I was able to remove some code that required P-Invoke (think this is a step in the right direction).

Update, 2013-01-27: I spiled Visual Studio´s glyph-service to show icons in the results view…

dark-theme-ui-2

Update, 2013-02-02: The extension is almost feature complete; I am working on some details now. For instance, the new version of the tool doesn´t show a progress-dialog anymore. Instead it has a thin progress-indicator that is embedded into the view (so it behaves the same way as many other tool windows in Visual Studio do).

dark-theme-ui-3

I reworked the trend icons (up- and down-arrows) and used the color´s of Visual Studio´s light theme, so I can switch luminosity depending on the selected theme, to make them look good…

dark-theme-ui-4

dark-theme-ui-5

How to export reports to Excel

Sometimes it could be helpful to export the result data to Excel, in order to work with the calculated data using common reporting tools, or if one want simply prepare data for a presentation, or just show and explain metrics to people having a less technical background. The latest update (version 1.5.0) allows to save reports to Excel 2007/2010 compatible worksheets. Exported documents contain all information available by the user interface. In addition default column filters are applied and cells with calculated values are colored – depending on the metric, scope and their current value. Rows are grouped by module, namespace and type – so the the document allows to navigate through the hierarchy very quickly. There is no special “Export” button in the UI – just select the Excel file format from the filter list within the “Save file” dialog, in order to save the report as an Excel document.

How to get rid of the errors CA0055 and CA0052

During the last weeks some users were complaining about the error messages CA0055 and CA0052, which will be reported by the Power Tool, if an invalid target file is specified. The extension tries to obtain the assembly filename from the project file by using MSBuild property evaluation (it´s looking for the TargetPath-property). In some situations the property evaluation fails, if the OutputPath- and PlatformTarget-property is not specified. In that case the evaluated value of the TargetPath-property will only contain the name of the output assembly file, but not the full path.

I couldn´t simulate that behaviour just by making changes to the build-configuration or project properties of projects created by Visual Studio 2010, but I have seen that behaviour in some older projects which were created using the 2005/2008 version and upgraded to a Visual Studio 2010 solution. The interesting thing is that this problem can´t be fixed by cleaning up build- and platform-configuration using the Visual Studio dialogs, because Visual Studio won´t change any customized (or manually added) elements within the project file (which is good). So, we have to fix this problem by manually editing the project file… Don´t worry – this is quite easy (-:

Open the project file using an editor of your choice… if you´re using Power Commands for Visual Studio, you can use the “Edit Project File” command. You´ll find a property group containing an element named “Platform” having a condition, which ensures that a valid value is specified. In the following example the value “x86” will be used, if the property is empty (correct me, if I am wrong, but I think this is the default configuration for Windows Forms and WPF applications created by Visual Studio 2010).

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
    <ProductVersion>8.0.30703</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{E1FAB955-3610-4315-BE54-DAF9EE9F4533}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>WindowsFormsApplication1</RootNamespace>
    <AssemblyName>WindowsFormsApplication1</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <TargetFrameworkProfile>Client</TargetFrameworkProfile>
    <FileAlignment>512</FileAlignment>
  </PropertyGroup>

Okay; this will work, if you have another property group like this…

  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DebugType>full</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <CodeAnalysisIgnoreBuiltInRuleSets>true</CodeAnalysisIgnoreBuiltInRuleSets>
    <CodeAnalysisIgnoreBuiltInRules>true</CodeAnalysisIgnoreBuiltInRules>
  </PropertyGroup>

This property group depends on the Platform- and Configuration properties defined earlier; if the values are “x86” and “Debug”, the properties of this group will be defined and can be evaluated by MSBuild. If you´re using a different platform configuration like “Any CPU” and/or “Release”, the evaluation will fail and the Power Tool can´t analyze the assembly. Notice that Platform and PlatformTarget is not the same (-:

Depending on your build configuration, you can add more property groups having different conditions. For example…

  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DebugType>full</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <CodeAnalysisIgnoreBuiltInRuleSets>true</CodeAnalysisIgnoreBuiltInRuleSets>
    <CodeAnalysisIgnoreBuiltInRules>true</CodeAnalysisIgnoreBuiltInRules>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <Optimize>true</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <CodeAnalysisIgnoreBuiltInRuleSets>true</CodeAnalysisIgnoreBuiltInRuleSets>
    <CodeAnalysisIgnoreBuiltInRules>true</CodeAnalysisIgnoreBuiltInRules>
  </PropertyGroup>

To cut a long story short: Make sure, that you´ve definded at least one property group that matches with the default values of the Configuration- and Platform-properties. This property group must contain the OutputPath- and PlatformTarget-properties. A good verification of the project file is to build it using MSBuild from the command line (without any additional switches).

So, now it´s up to you to fix your project file(s)…

Small things, big impact (-:

Howdy! A new release is available. You can now open the Code Metrics Viewer from within the Solution Explorer; just right click the solution node, there you´ll find the “Code Metrics Viewer” menu item…

The configuration of the Code Metrics Tool Path is now a bit easier… if you have successfully installed the Code Metrics Power 10.0 you can use the “Locate Metrics Tool Path”-button in the options dialog to obtain the installation folder automatically.

Hope you enjoy the new features (-:

Is it possible to compare metric results?

Yes, it is! The latest version of the extension has basic comparison functionality. I thought this could be very helpful, if one would use the extension during code review and/or refactoring. When I used the tool during re-factoring, I had the problem that it was hard to see, if values were getting better or worser. So, I thought it would be nice to load a previously calculated report and compare the data against the latest results, to be able to show some kind of “trend” within the grid. This is one of the features I wanted to wait with until end of this summer, because there is still some work to do… in other words, by now it´s not perfect :-) In some situation the comparison might not work…

I calculated metrics for a very simple console application… Here you can see the Main()-method of the static Program-class, which has a maintainability index of 57. Of course, this is still okay, but it could be better…

So, I made some refactorings to the Program-class… I created two new methods named ExtractPublicKey() and WriteKeyFile, recompiled the assembly and calculated the metrics again…

Now I can use the compare feature, to see if I made some “good” progress :-) As you can see in the screenshot, there is a new button named “Compare…” in the toolbar. If you press that button, a file dialog will show up, where you can select the candidate report for comparison. If you want to work with the compare feature I recommend to enable the auto-save functionality in the options dialog – so, a new report will be stored in the solution folder, each time you calculate code metrics.

In my example I have choosen the report, which was calculated before I did the refactorings – and I see, that the maintainability index increased by 7.

By the way… if you like the tool, I would be glad if you would rate the tool with five-stars in the Visual Studio Gallery :-)

Calculated results can be kept for further analysis

In accordance to the test tools for Visual Studio Professional, the extension stores a compound report containing all calculated results of the solution in a folder named “MetricResults” below the solution directory. The output path can be changed in the “Reports” options page. The output path can either be a relative or an absolute path, but Visual Studio macro´s are not supported. The “Auto-Save”-feature is enabled by default. So, each time a report is calculated it will be stored in the configured output directory. The number of automatically saved reports can be limited, so the extension will only keep the latest results – the default value is 25. If you set the limit to zero, all reports will be kept; nothing will be deleted.