Jane's Technical Stuff
Archives
May 2002March 2003
May 2003
July 2003
August 2003
June 2005
July 2005
August 2005
December 2005
January 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
Friday, June 13, 2008
More on FxCop Command line integration into Visual Studio
We've done some more work on integrating FxCop into our development process this week, and today Mike and I have sat down and started work on choosing which rules to validate against initially. To do this, we've based our starting set on the rules that Microsoft have switched on internally. Thus far we've been through the Design, Naming (mostly left switched off until the coding standards review is complete) and Performance rules.
Having set these up in a .FxCop project, I then wanted to be able to make use of the Post Build event to get the assembly analysed according to a predefined set of rules. This took a bit of research but I think I've got it sorted now:
Instead of using:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
I'm using
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" /project:"C:\Program Files\Microsoft FxCop 1.36\DefaultRules.FxCop"
and so am making use of the "/project" flag to specify the .FxCop file to run, and no longer specifying the /r (or /rule) tag to indicate where to find the rules. It is important that the .FxCop file doesn't contain any targets of its own, as otherwise both the assembly produced by the build AND the assemblies targetted in the .FxCop file will be analysed, which could lead to a lot of head-scratching when you try to work out why a source file that doesn't exist is causing problems :-)
More information on the options for the FxCop Command Line version is available here.
Having set these up in a .FxCop project, I then wanted to be able to make use of the Post Build event to get the assembly analysed according to a predefined set of rules. This took a bit of research but I think I've got it sorted now:
Instead of using:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
I'm using
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" /project:"C:\Program Files\Microsoft FxCop 1.36\DefaultRules.FxCop"
and so am making use of the "/project" flag to specify the .FxCop file to run, and no longer specifying the /r (or /rule) tag to indicate where to find the rules. It is important that the .FxCop file doesn't contain any targets of its own, as otherwise both the assembly produced by the build AND the assemblies targetted in the .FxCop file will be analysed, which could lead to a lot of head-scratching when you try to work out why a source file that doesn't exist is causing problems :-)
More information on the options for the FxCop Command Line version is available here.
Labels: static code analysis
// posted by Jane @ 2:00 PM 
Comments:
Friday, June 06, 2008
Static Code Analysis Review: Summary
It took a while, but we've finally reviewed our static code analysis tools and made a proposal to use FxCop.
Of the tools we evaluated there were 2 main contenders - FxCop and Submain CodeIt.Right which I've covered in more detail in other blog posts.
The other tools, NDepend, Visual Assist and Resharper, didn't get close enough to our criteria on a number of points. NDepend and Resharper look like valuable tools, but not under the mantle of what we wanted from static code analysis. VisualAssist was more of a tool to help whilst you type - adding to the intellisense and providing prompts for syntax violations.
Note: We don't run Visual Studio team edition so there is no built in code analysis tool
Of the tools we evaluated there were 2 main contenders - FxCop and Submain CodeIt.Right which I've covered in more detail in other blog posts.
The other tools, NDepend, Visual Assist and Resharper, didn't get close enough to our criteria on a number of points. NDepend and Resharper look like valuable tools, but not under the mantle of what we wanted from static code analysis. VisualAssist was more of a tool to help whilst you type - adding to the intellisense and providing prompts for syntax violations.
Note: We don't run Visual Studio team edition so there is no built in code analysis tool
Labels: static code analysis
// posted by Jane @ 5:34 PM
Comments:
Static Code Analysis Review: FxCop
This is a tool I've used in the past with success, but which I found frustrating by the lack of integration into the IDE, instead relying on its own, slightly gawky interface.
Rules can be switched off, switched on, and also custom rules can be added - read this tutorial for some useful hints and tips. Rules can also be supressed on a project by project basis, or globally by updating the FxCop.targets file - this will be really handy for how we want to set our chosen tool up.
I left the rules as default, so they are based primarily on the Microsoft Design Guidelines. When run through the FxCop IDE a helpful link is provided to online documentation explaining the issue in more detail - for instance AssembliesShouldHaveValidStrongNames - and giving example fixes. The quality of errors returned were much better than CodeIt.Right, referring both to coding standards (naming of variables etc), but also performance and security improvements. There is no automagic correction meaning that developers learn from the warnings.
There is a command line version of the tool available which can be built into an automated build process. Additionally, this can be added as a post-build event outputting the results into the Warnings tab of the Error window in VS2005 and VS2008.
Configuration
Rules can be switched off, switched on, and also custom rules can be added - read this tutorial for some useful hints and tips. Rules can also be supressed on a project by project basis, or globally by updating the FxCop.targets file - this will be really handy for how we want to set our chosen tool up.
Error detection
I left the rules as default, so they are based primarily on the Microsoft Design Guidelines. When run through the FxCop IDE a helpful link is provided to online documentation explaining the issue in more detail - for instance AssembliesShouldHaveValidStrongNames - and giving example fixes. The quality of errors returned were much better than CodeIt.Right, referring both to coding standards (naming of variables etc), but also performance and security improvements. There is no automagic correction meaning that developers learn from the warnings.
Automation
There is a command line version of the tool available which can be built into an automated build process. Additionally, this can be added as a post-build event outputting the results into the Warnings tab of the Error window in VS2005 and VS2008.
Labels: review, static code analysis
// posted by Jane @ 5:34 PM
Comments:
Static Code Analysis Review: CodeIt.Right
Initially this looked like it was going to be our best fit tool - it integrated into the IDE really well, it became an option on the tool menu and had a really simple interface for configuring and examing the rules.
Configuring rules was simple on a project by project basis - not sure how easy it would be to configure on a wider basis - so that all the rules are shared across many solutions. It is theoretically possible to add a custom rule making use of an SDK and code editing - there is a tutorial on this.
The errors returned are grouped by project, making filtering really easy. It even gives an ability to automagically (their word not mine) correct code errors and violations. When I tried this, my project didn't build any more, although I suspect this may have had something to do with dependency issues - any altered code through this process was commented, such as
//ENCAPSULATE FIELD BY CODEIT.RIGHT
The errors returned for my test project didn't seem to be to as granular a level as I've experienced previously with FxCop - this was a concern.
There is a command line version available which can be incorporated into an automated build process.
Configuration
Configuring rules was simple on a project by project basis - not sure how easy it would be to configure on a wider basis - so that all the rules are shared across many solutions. It is theoretically possible to add a custom rule making use of an SDK and code editing - there is a tutorial on this.
Error detection
The errors returned are grouped by project, making filtering really easy. It even gives an ability to automagically (their word not mine) correct code errors and violations. When I tried this, my project didn't build any more, although I suspect this may have had something to do with dependency issues - any altered code through this process was commented, such as
//ENCAPSULATE FIELD BY CODEIT.RIGHT
The errors returned for my test project didn't seem to be to as granular a level as I've experienced previously with FxCop - this was a concern.
Automation
There is a command line version available which can be incorporated into an automated build process.
Labels: review, static code analysis
// posted by Jane @ 5:13 PM
Comments:
Wednesday, May 28, 2008
Integrating FXCop into Visual Studio 2008
I was using the FXCopAddin for VS2005 but I couldn't get it to work for VS2008. The FXCopAddin didn't seem to have been updated for quite some time, and so I didn't have high hopes of it becoming compatible anytime soon. I really liked the integration that the AddIn gave me, the fact that my warnings were shown in the standard VS error window etc, so I wanted to find a similar, alternative solution.
I started with working out the command line version of what I was trying to do -
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"C:\Working\MyTestApp.exe" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
Which is, basically, call FXCop (version 1.36) using the Rules dlls specified in "C:\Program Files\Microsoft FxCop 1.36\Rules", and use the XSL file in "C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" to formulate the output.
Moving on from this, I put this working command line into the Post-build event command line as:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
Where $(TargetPath) gets equated to the generated dll/exe etc in the build process.
Behind the scenes, this gets recorded in the .csproj file as:
<PropertyGroup>
<PostBuildEvent>"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"</PostBuildEvent>
</PropertyGroup>
And bingo, the errors get reported into the warnings window. From here they are clickable etc.
I started with working out the command line version of what I was trying to do -
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"C:\Working\MyTestApp.exe" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
Which is, basically, call FXCop (version 1.36) using the Rules dlls specified in "C:\Program Files\Microsoft FxCop 1.36\Rules", and use the XSL file in "C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" to formulate the output.
Moving on from this, I put this working command line into the Post-build event command line as:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
Where $(TargetPath) gets equated to the generated dll/exe etc in the build process.
Behind the scenes, this gets recorded in the .csproj file as:
<PropertyGroup>
<PostBuildEvent>"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"</PostBuildEvent>
</PropertyGroup>
And bingo, the errors get reported into the warnings window. From here they are clickable etc.
Labels: static code analysis
// posted by Jane @ 5:35 PM
Comments:
Wednesday, April 02, 2008
Static Code Analysis Review - our criteria
The criteria we've come up for choosing a Static Code Analysis tool are the following:
Is there anything else we should be thinking about?
Note: We've excluded cost as we're interested in finding the right tool without thinking about budgetary constraints.
- Integration - how well does it integrate with VS2005. Does it claim to integrate with VS2008? What about legacy VS2003 stuff?
- Versions - can it work against a .NET 1 project? Or a .NET 3/3.5 one?
- Ease of use - how easy is it to run an analysis? How easy is it to understand what it wants you to fix? And where the code is?
- Ease of configuration - how easy is it to add a new rule? Or turn one off?
- Issue detection - running it against a specific project, what does it detect? How many potential issues does it spot? How does this compare the other tools?
- Stability - any problems noticed since installing it/using it?
- Extra - what else is there about this tool? Any added bonuses?
Is there anything else we should be thinking about?
Note: We've excluded cost as we're interested in finding the right tool without thinking about budgetary constraints.
Labels: .NET, C#, Development, static code analysis
// posted by Jane @ 12:02 PM
Comments:
Thursday, March 27, 2008
Static Code Analysis
One of my colleagues and I are looking into tools for Static Code Analysis for C#. At the moment, we have the following tools on our list to investigate further:
Do any of my readers have any suggestions for other tools we should consider? If so, please leave me a comment with the name and any feedback.
Do any of my readers have any suggestions for other tools we should consider? If so, please leave me a comment with the name and any feedback.
Labels: .NET, C#, Development, static code analysis
// posted by Jane @ 6:32 PM
Comments:
