Beautify your [C#] code with Microsoft Source Analysis

Hear hear! Microsoft has just released Source Analysis for C# tool! This tool analyzes C# source files for compliance to set of rules in different categories, namely

• Documentation category contains rules related to code documentation (such as "File must have formatted header" or "Elements must be documented")
  
• Layout rules are rules related to text formatting (where curly brackets should be placed etc.)
  
• Maintainability rules are the ones related to default specifiers and missing descriptions (f.e. Debug.Assert without text)
  
• Naming rules are similar to such FxCop rules
  
• Ordering rules check the order of declarations within namespace/class
  
• Readability rules verify that the code does not contain not required extras (such as redundant base specifiers)
  
• Spacing rules check for correct number of spaces in various situations
  

In all there around 200 rules provided!

The tool is installed as VS 2008 Integration Package providing tight integration with IDE. Once installed, two additional menus are available for C# projects in Solution Explorer – one to invoke Source Code Analysis, and another to configure analysis setting per project.

The configuration is somewhat similar to Static Code Analysis rules configuration (but you can look at hint window for rule detailed description)


"Run Source Analysis" menu is located right next to "Run Code Analysis"


Once you run it, Errors tool window will contain source analysis (SAxxxx) errors to handle


Additionally, there is MSBuild targets file (that may be optionally installed as part of the tool installation) that allows running Source Code Analysis as part of the build. Read the article detailing howtos on the development team's blog.

The application's first public release is 4.2 (since the tool was used internally at MS for quite a while) so it is full-featured and quite stable one. I am very excited by that release; in my opinion it may compare to first FxCop release by its importance (and it is free as is FxCop).

And according to the team's blog, the next version might also provide automatic fix options for some rules!

Static Code Analysis presentation goodies

This Wednesday it was my pleasure to present Microsoft Static Code Analysis tools stack to SF .Net user group. Thanks to everyone that has showed up after a busy day for the evening of Static Code Analysis!

Here are some related links:

• Download presentation slides in PowerPoint 2007 format
  
• Download latest version of FxCop
  
• Download Visual Studio Team System/Team Foundation Server trial VPC image
  
• Download code samples for code metrics (courtesy of Conor Morrison at VSTS code analysis team)
  

If anyone has any followup questions or ideas related to the presentation, drop me a line at eugenez_at_attrice_dot_info.

Microsoft loves you – three free tools

Sometimes it is not easy to refrain from posting links instead of original content :) But there are three recently released tools that richly deserve advertising.

Framework Design Studio allows comparing different versions of the same managed library (in binary form). You can filter the interface content being compared, comment on the differences and save the output as MS Word 2007 document.

I have tested the application a little, and it packs surprising amount of functionality. One thing to be aware of is that the user interface is somewhat quirky, so make sure you read the manual before using the app (manual docx is installed as part of the application package).

Typical usage for the app would be to compare new version of third party (meaning only binary is available) library with previous version, in order to discover the changes to interface. Another application I could think of would be to produce sort of release document to be distributed with the new versions of given library (since FDS allows commenting the differences and produces very nicely formatted Word document – beats documenting interfaces changes manually).

VSCT Power Toy is a small application that Visual Studio package developers will kill for. It retrieves command tables (including all ids) from VS packages or VS registry, and even nicely formats it for copy/paste to .vsct file. Anyone who did it without this app can appreciate the difference (look at my previous post if you want to get a feeling). I practically drooled all over the screen with this tool running

Patterns & Practices Documentation Tools is set of instruments Patterns & Practices team uses to create documentation. The tools are Word 2007 (English only) template with macro and associated toolbar to create well-formatted content and PowerShell scripts to convert the document authored through template to HTML, CHM or HxS. I did test the template, and the process of authoring document appears to be pretty smooth. The converters, on the other side, require bunch of things to be installed (in addition to PowerShell). But if you look at P&P produced documents, the result probably worth some extra work.

MSBuild goes famous, MSDN docs don't

It looks like MSBuild 3.5 got a new champion – none other than Scott Hanselman himself! He recently published two posts on how build time may be drastically improved on multi-core machines with new 3.5 multiprocessor support.

While I certainly like that additional visibility for MSBuild coming from the popular online author, for me it also indicates something else (not as positive) – most people become really allergic to MSDN content, to the point where they never read it. In later years, MSDN content tends to be late/incomplete/not helpful, so it ceased to be first resource you look into (for MS technologies, that is). And additionally, the visibility of MSDN content in the search engines results is so lame, the content may just as well be non-existent.

But for MSBuild, the content is there, and it provides very decent handling of various MSBuild topics. For example, speaking of 3.5 specific features:

• Building for multiple processors
  
• Targeting specific .NET frameworks with MSBuild (aka ToolsVersion Project attribute)
  
• Item Definitions (aka ItemDefinitionGroup element)
  
• New Methods for Manipulating Items and Properties (properties and items under Target element, Remove Item attribute)
  
• Registry Look-Ups
  

Overall, MSDN MSBuild content node contains loads and loads of pertinent information. So I thought – what's the heck, I shall try to provide some visibility for the good stuff.

And speaking of content, if you are interested in everything MSBuild there is couple of must-have blogs to follow: MSBuild Team blog and Sayed Hashimi's blog. Oh, and probably Scott Hanselman will chime on as well, so make sure you keep reading his blog!

Sharing files between VS projects

One of the interesting features available in Visual Studio managed projects (VS2005 and VS2008) that I keep forgetting about is the ability to add same file to several projects as "link" rather as physical copy. To add existing file to the project as a link you just need to select "Add->Existing Item" and then use well-hidden "Add As Link" add option in the dialog:



The file added as link then will have special icon in solution explorer. And if the file linked is under source control, it will not be added to repository again; the icon will show the status of original file.

What is this feature good for? Several examples:

1. You have class library project where some class have internal methods, and you want to use those methods (for example, for testing). Then you can create additional project and link the files from the class library into it – and voila! you can use internal logic and do that in separate project
   
2. Share certain file between several projects. You might wonder what file is a good candidate for that kind of sharing; well, how about AssemblyInfo.cs file? That way you can easily make sure that all related assemblies have the same version
   
3. One interesting usage scenario was mentioned on MSDN forums: it is not a secret that when you build managed project it generates lots of junk in the project folder (obj and bin folders come to mind). While you can redirect output, it turns out getting rid of this obj folder is quite involved. But suppose you stored your source files elsewhere and would just link them into the project being built? That way you can make maintain clear separation between source code and build plumbing (which is the main purpose of C#/VB project)
   

I am not advocating the wide usage of the links instead of good ol' files; but that's a neat alternative to be aware of.

Debugging Visual Studio packages (stories from the crypt)

If you ever developed Visual Studio integration package, you should be familiar with load failure problem. The problem manifests itself when properly deployed package cannot be loaded with error message displayed.

I'd like to stress the deployed part of the above; when such problem occurs in the development environment, there are number of typical issues causing this such as invalid registry (missing CodeBase attribute etc.), invalid PLK key or missing dependencies (am assuming here that package with invalid PLK does not get distributed :). To diagnose such issues one can use Package Load Analyzer, distributed as part of Visual Studio SDK.

However, when the issue occurs at some other workstation where properly tested package is deployed, this option is not too useful (you cannot ask every user to install VS SDK, can you?). And believe it or not, these things happen even to the software that is rock solid in local test environment. So here is my take on figuring out why deployed package does not work:

1. Ask the user to export registry branch with package registration information
   
2. Ask the user to run Visual Studio with logging enabled (devenv /log [log file path]) and ship you the log; the log will tell you if you have PLK or similar problems – in a sense it is performing the same function as Package Load Analyzer only without fancy interface
   
3. And finally, do tracing in your code! By "tracing" I mean trace every single dubious statement in package Initialize method (and every exception elsewhere however unlikely it might seem). Though better approach would be to utilize Visual Studio Output pane, sometimes the overhead is too big for unlikely scenarios. But however unlikely, if you put Trace statement in that location it can be crucial in diagnosing the problem. Mind, I advocate tracing over message boxes and other UI elements only for the problems that are deemed unlikely (that is never occur in testing, for example).
   Then if you have copious tracing embedded in your code, you can instruct the user to place diagnostics section as into devenv.exe.config file (located in IDE folder together with devenv.exe) and thus get the snapshot of what is going on in your package
   

This sequence can be pretty helpful in diagnosing problems in packages that otherwise are functioning properly in most environments. If you have alternative approaches, it would be interesting to learn them – leave a comment on the blog!

Look and ye shall find. Or may be not.

Do you think that you could list the ways you employ to minimize the number of bugs in the software? It could have been an interesting exercise (similar to 5 facts about yourself nobody knows etc). Well, Patrick Smacchia of NDepend fame did it for you – here are seven (like in seven deadly sins :) typical ways to minimize number of bugs in the software.

I liked the post very much (and still do) but eventually I started thinking that I do not agree with some of the things said. So there – my take on those seven.

While I have no argument about Contract, Automatic Tests and Empirical Approach as effective ways of fighting bugs, other categories do not seem to me a bit questionable.

Prioritizing bugs fix over new features development is a good tactic when one can truly estimate the stability of the code. But frequent is the situation where the code is considered to be worth making more stable through bug fixing; but the stability of the code never actually increases. As the stability (increase) cannot always be estimated numerically, this technique to me seems to be giving a big name to somewhat arbitrary decisions of deciding what to maintain and what to leave alone.

Code quality that is supposed to be brought about through changes in programming styles such as LINQ is in the very least arguable. The argument VB is better than C++ since it is easier to understand comes to mind. Very good post on new trends that will revolutionize software development can be found here – I rather tend to subscribe to that view.

Finally, positioning Code Review and Static Code Analysis as tools for finding bugs misses the point. If we talk about doing code review (static code analysis can be thought of as automated code review process) in order to identify bad "smell" coming from certain piece of code (which FxCop does well) or coming from certain modules/design decisions (in which NDepend excels) that is a one thing; but to use code review (in any form) to find actual bugs always was pretty ineffective. While Patrick says so in his post, he still puts code review into his list. I wouldn't – I would rather call that code quality assessment using whatever tools are available (old-fashioned peer code review, static code analysis, Line Of Code counting whatever); and such an assessment would result in devoting more time to testing the questionable areas.

And what will be your take on bug fighting techniques – speaking theoretically?

Hear hear - VPC is here!

It is Fools' Day, but that is no joke –VS2008 Team System Trial VPC is released. It is full of goodies (nice touches include Office SP1 and Power Tools pre-installed) and it will expire in December (right, December) 2008. And if that is not enough, it has 38 labs with data inside.

If you do not have VPC and poo-poo it as a waste of bandwidth (well, yes, it is around 5 Gb compressed) I'd advise you think about getting one. VPC is invaluable for doing crazy things in TFS repository and verifying changes before going live. Get one and be wise!

Influence next version of Visual Studio Team System

If you interested in influencing the next version of VSTS, the team publishes the specifications of the features under development for public feedback.
In February, the following specs were published:

• TFS Bug Submission portal for TFS 2008 - contrary to current Web Access UI, new bug sumbmission Web UI will provide kind of access that will not require Client Access License; kind of "my work items only" management web interface (and mind you, that feature targets TFS 2008, so make sure to have a look!)


• Send mail from TFS - the feature will implement mailing one or list of work items from VSTS


• Linking Work Item tracking - the feature spec describes the future customizable link relationships to be supported in the next version of VSTS

The following specs were released a while ago:

• Add to Source Control


• History improvements


• Improved labels dialog


• Resolve conflicts improvements

By the way, you can view the historical list of specs for VS2008 aka Orcas here - just for inspiration :).

Branching to desired target path is easy

One would expect that creating a branch is pretty well trodden path today; that's why it was kind of shock to me that there are still people out there, that do not know how to do that efficiently.

The problem is simple – you want to branch folder "$/Project/Ongoing" to "$/Project/Branches/1.1". And here is the wrong way of doing it:

1. Invoke Branch dialog by right-clicking the selected path and selecting "Branch…" menu
   
2. Select the desired destination path for new branch in Target control
   
3. Hit OK to perform branching
   

The problem is, you end up with new branch created at "$/Project/Branches/Ongoing" (as illustrated below).

And since what you actually wanted is not a branched folder named "Ongoing", but one named "1.1", you end up renaming newly created branch. Red light flashing - wrong answer!

Here is the correct walkthrough:

1. Invoke Branch dialog by right-clicking the selected path and selecting "Branch…" menu
   
2. Select the desired destination path for new branch in Target control
   
3. Add desired name for the target branch folder to the specified path in Target ("$/Project/Branches/1.1")
   
4. Hit OK to perform branching
   

And voila! The desired branch folder is created

Since the behavior does not seem to be very intuitive to me (and to some people I know), I thought it is worth blogging about.