A couple of new Orcas features for Managed Code Analysis [David Kean]
Yesterday our team, Code Analysis, checked-in the last of our scheduled feature work for the next version of Visual Studio; Orcas. Now that I have a little time up my sleeve, I thought I would cover a couple of new features that you may have already seen in the Orcas October CTP.
First, before I detail what these are, a little background.
The Code Analysis team jumped on the Visual Studio 2005 product cycle late. By the time customers first saw our bits in Beta 2; most teams on the product had either finished or were winding down. This, unfortunately, did not allow enough time for other teams to fix the new Code Analysis warnings (such as this) that started to appear on both their generated and templated code.
Even if there had been time, some of the generated code, DataSets for example, contained members that represented tables and columns in a database that were outside of the control of the tool generating it. Although Managed Code Analysis had the ability to suppress these warnings in source, users quickly found that they were blown away as soon as the code was regenerated; thereby causing the warnings to reappear the next time Code Analysis was run.
To counteract this, we made late changes to particular rules (mainly in the Design and Naming categories) that would cause them to bail on analysis when run over code generated by specific code generators (indicated by the GeneratedCodeAttribute). This had the effect of ‘hiding’ found warnings from the user.
As we moved towards the next version of Visual Studio (Orcas), we started to think about better ways to handle the above situation. On one hand, we wanted to make users aware of any issues with the generated code (ie that it might break any currently turned on rules – including those enforced by check-in policy), but on the other, we still wanted users to have explicit control over whether they want to see these issues or not. Therefore, we came up with two solutions.
The first solution involves a simple option. In the Code Analysis property page available for C++ and MSBuild-based projects, you will notice that we have added a new option; Suppress results from generated code:
Turned on by default and as the name suggests, this has complete effect of hiding all results from generated code. Turned on; you will not be notified on any warnings against code marked with the GeneratedCodeAttribute, turned off; you will be notified of all warnings. As part of this work, we also ripped the special checks above that caused rules to bail on specific code generators.
The second feature involved splitting up the Suppress Message(s) menu item when right-clicking on a warning:
The first menu item, In Source, allows you to apply the suppression against the code element itself, (in the example above; against the property). The second menu item, In Project Suppression File, allows you to apply the suppression in a completely different file, which by default is called GlobalSuppressions.cs. This prevents the suppression from being blown away when the code is re-generated and has the advantage of storing your suppression in one central location.
If you want to start playing around with these features, download the October CTP and tell us what you think over on the Managed Code Analysis forum.
Although these two features are rather minor, don't be worried that this is the only thing new in Orcas for Code Analysis. We still have a few new features (including a major one) hidden up our sleeves, which we will talk about in future posts.
Comments
Anonymous
January 03, 2007
Martin Hinshelwood on Tim That Task VSTS Check-In Policy. Brian Harry on New TFS Tools Available....Anonymous
January 07, 2007
I've noticed that Code Analysis sometimes places suppressions in a file called GlobalSuppression.cs (GlobalSuppressions.vbAnonymous
January 12, 2007
Update: A Virtual PC image is also available. We've just released the Visual Studio 'Orcas' - JanuaryAnonymous
February 27, 2007
Did anyone there think to get the teams responsible for the code that causes the Code Analysis warnings to actually fix the code for the upcoming release?Anonymous
February 28, 2007
RayMartinsHair (obviously an Aussie), We did, hence the call out over here: http://blogs.msdn.com/fxcop/archive/2006/04/11/WeWantYourFeedback.aspx. However, unfortunately, it's not always the tool generator at fault, DataSets pull their member names from databases, Web Service proxies from external Web Services, etc, so sometimes the violations are outside their control. We also can't pester teams outside of Microsoft to fix their violations.Anonymous
May 06, 2007
If you've been living under a rock (or just distracted by this Silverlight thingy), you might have missedAnonymous
November 19, 2007
Both Code Analysis and Code Metrics make extensive use of CompilerGeneratedAttribute and GeneratedCodeAttributeAnonymous
November 22, 2007
In previous posts about Code Metrics and Code Reviews , I explored some metrics and techniques that I