StyleCop Check-in Policy updated (v 1.3)

I have updated TFS check-in policy for StyleCop 4.3.3.0 and also compiled a version for TFS 2010 (now that it has RTM’ed).

The sources and MSIs (one for TFS 2008 and one for TFS 2010) are now available at MSDN Code Gallery.

Enjoy!

Mirror from my MSDN blog

TFS2010: Connecting using TFS 2008 object model

Can you connect to TFS 2010 server using 2008 client? Sure you can! There are couple of gotchas to be aware of, specifically you’d be better off installing an update for TFS 2008; if you do not the following message comes up:

Grant Holliday wrote very detailed post on what needs to be installed and what to do if for some reason you cannot install the update.

However, I wanted to mention this in context of custom tools that use object model. While connecting to TFS 2010 with Team Explorer 2008 will produce the message above (and will require extra steps such as update installation to get TE working), the message won’t appear for your custom tools. In fact, if the connection to TFS 2010 is defined in registry you will connect and may not know the difference from inside of your tool.

Thus if you have custom tools using 2008 OM connecting to TFS 2010, it is your responsibility that the update gets installed correctly on machines with the tools.

Mirror from my MSDN blog

StyleCop checkin policy updated for StyleCop 4.3.2.1

StyleCop check-in policy was updated for the latest build of StyleCop available (4.3.2.1). The only change in this drop is newer StyleCop reference assemblies.

Version 1.2.2 of the policy is available as MSI installer (available AS IS).

Related posts:
- Updated StyleCop Checkin Policy (v1.2.1)
- StyleCop 4.3 Checkin Policy version 1.2
- StyleCop 4.3 Checkin Policy available
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

Disposing of checkin policy

Recently while I was fixing up StyleCop checkin policy, I came across one small not-so-obvious snippet of knowledge worthwhile to share.

Any custom checkin policy inherits from PolicyBase, which in turn implements IDisposable. Meaning – if you need to clean up after yourself in your custom policy, Dispose method is the place for that.

So in StyleCop policy, I do a lot of Visual Studio related stuff and thus I thought I’d dispose of VS extensibility objects in Dispose method.

And here where non-obvious stuff starts. The policy is loaded in either of those cases:

• Project Source Control configuration (through menu Team->Team Project Settings->Source Control)
• Right-clicking in Solution Explorer and invoking “Check In…” menu
• Invoking “View Pending Changes” toolwindow

While the first case is not very interesting (no pending changes will be evaluated in configuration), two other cases are important.

In case of “Check In …”, “Check In” modal window is displayed (the policy is loaded), and when window is closed, custom policy class is unloaded and Dispose called. However, in case of “View Pending Changes” toolwindow the policy is loaded once when window is first created, and Dispose will be called only when Visual Studio is closed or TFS server connection is closed. That means you probably should not hold on any expensive resources until Dispose.

New check-in policy for VSS fans: keywords expanded

One of the much-talked-about missing features of TFS is the keyword expansion feature. You know, the ability to place the template in the beginning of every single file and then have every revision tracked in the body of the file (in addition to tracking in source control history, that is).

Personally, I am not a huge fan of the feature – mostly because the usefulness of the feature limited by the following factors

1. The comments to check in still have to be detailed (if the comments are crappy, you get a lot of garbage in the file that adds nothing)
2. If the file gets branched a lot, the revision history tend to get muddy and not to reflect the branching history very adequately
3. If the code churn is great, you might get 100 lines of code adorned with 400 lines of revisions history (yes, I actually seen this)

So I am of the opinion that all of the above is the function of source control and if your source control is not good enough for tracking history of changes – that ain’t good source control :) However, for some folks ability to have history of changes contained in the same file outweighs the disadvantages. And these folks were pretty vocal, so vocal that Buck Hodges stopped one stop short of writing actual solution and provided the verbal recipe for writing one, using check-in policy as a workaround (since keywords expansion is not making it into official product).

And voila! Two years after this post was published, there appears TFS keyword expansion checkin policy, written by Jochen Kalmbach. Jochen also published the policy on CodePlex site, under the name of LogSubstPol.

I did a short test drive of the policy, and it does work as advertised, in three simple steps:

1. Install the policy (currently using batch script)
2. Add the policy to your Team project and configure the format of the keywords string
3. Add  keyword ($log$ etc.) monikers to the file modified prior to check in

Once all of that done (and steps 1 & 2 are once per project, step 3 once per file step), as you check in you will see the revision history being updated and checked in as part of the file.

While the policy is awesome, there are few things to be aware of.

• As the policy requires you to supply the comment, it effectively replaces “Changeset Comments Policy”, so if you have it defined for Team project you might want to remove it
• Configuration dialog for the policy is somewhat complex, so read the documentation first (supplied PDF is real good)
• If you evaluate the policy but decide not to check in, due to limitations of the checkin policy mechanism the keywords in the file will get expanded anyway
• As the files are updated by the policy, VS will display the message “The file has been modified outside of the source editor” (as policy touches it right before check in). That again may be limitation of the checkin policy mechanism for keyword expansion (but perhaps can be mitigated with some creative VSX tweaking)

But regardless of these small thingies, the policy is mighty useful and it fills the big gap for those accustomed to keyword expansion. Big kudos to Jochen for creating the policy!

Mirror from MSDN blog

Updated StyleCop Checkin Policy (v1.2.1)

After countless nugdes I have updated StyleCop check-in policy for newest build of StyleCop available (4.3.1.3). While at it, I was able to incorporate a few bug fixes and add improvements.

Version 1.2.1 of the policy is available as MSI installer or as zipped source code (available AS IS).

Bugs fixed are:

• Solution containing projects with same Name is not evaluated correctly (keying schema is now by Project VS object instead of Name)
• Same file appearing in different projects causes policy exception
• C# web site projects are now supported

For the last two items, huge thanks to Clement Bouillier for bringing them to my attention.

Additionally, I have added pretty neat feature (in my opinion) to improve the navigation for the errors found by the policy. When policy is evaluated, now any violation found is added both to Checkin dialog and to Visual Studio Error List pane. Thus you can review the violations in the form similar to non-policy StyleCop violations. Additionally, clicking on policy violation either in Checkin window or Error List pane now will bring up the file and the line the violation is found in.

Policy violations are cleared from Error List pane when the policy is re-evaluated or on project build.

If you encounter any issue with the new drop, please make sure to leave a comment (and I promise to handle the issues promptly this time).

And while at StyleCop topick, I’d like to point to an excellent project driven by Howard Van Rooijen – StyleCop integration with ReSharper. If you use both, make sure you get the latest drop from Codeplex.

Related posts:
- StyleCop 4.3 Checkin Policy version 1.2
- StyleCop 4.3 Checkin Policy available
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

Case of never ending unit tests

Couple of days ago I came across very weird issue on my new box – unit tests that were started (either from within Visual Studio or using MSTest command-line) would never complete. Test run would just hang pending forever.

Since I was running latest and greatest VS2008 with SP1, I have started blaming permissions first, and then new Windows bugs (since I was running Windows 7 build), and that did not help (does it ever?).

As it turned out, the problem was my computer name. It was all lower case (upper case does not exhibit the problem), and somehow that prevented unit tests run from ever completing (even without any TFS stuff – just plain unit tests). The workaround is to change the computer name (either using Computer->Properties, or by tweaking the registry if you cannot do it [for example, when computer is joined to a domain]). The steps are described in this helpful MSDN post.

Thanks for the workaround go to Ed Hintz.

Case of duplicate VSMDI files – resolved?

If you are using VSMDI files, chances are you know what I am talking about. You get all your test lists defined, tests running, sun is shining and suddenly, out of nowhere second and then third VSMDI files get created.

The problem is pretty irritating one, as can be witnessed by some angry posts at MSDN. The problem also seems to be a complicated one because it can happen in multiple scenarios, and some of those scenarios are not readily reproducible. The reproducible scenarios are:

• The solution with VSMDI file is not under version control, but VSMDI file is read-only. When Visual Studio needs to change it, new file (with suffix 1, 2 etc.) is created
• The solution with VSMDI file is under version control, and VSMDI file is checked out with exclusive lock. When Visual Studio needs to change it, automatic check out is attempted and fails, and new file (with suffix 1, 2 etc.) is created

Other scenarios appear to involve Test List editor tool window, and not reproducible in 100% of cases.

So you’d say – that’s all very interesting, but how about fixing that? There are several ways to go about it.

First of all, scenarios involving read-only VSMDI files should be easily fixed (by removing r/o flag). In case of source controlled solution, there is KB support article 957358 detailing steps to avoid that.

Secondly, there is piece of advice that I really like (courtesy of Chris Menegay) – always modify VSMDI files by double-clicking the file in Solution Explorer (and not by using Test List editor etc.). From my experience, it appeared to work magically.

And lastly, most of these scenarios are fixed in Visual Studio 2008 SP1. If you have installed service pack, and still observe duplicated files appearing, folks at MS would be every interested to know about it. Leave a comment or drop me a line.

In next version of Visual Studio, VS 2010, the pain associated with VSMDI files should go away as there is a whole lot of changes in the way testing is done.

StyleCop 4.3 Checkin Policy version 1.2

Since the last release of the policy, I have received several comments that required attention, and finally I was able to make changes to the code.

Version 1.2 of the policy is available as MSI installer or as zipped source code (available AS IS), and contains the following new features:

• Ability to import settings from existing *.StyleCop settings file when creating new policy
• Support for VS projects placed under solution folders
• Every StyleCop analysis violation is displayed as separate check-in policy violation; summary window is still available when double clicking the policy violation

Using the occasion, I would like to touch upon some points in policy implementation detail

1. Policy needs Visual Studio to execute, since it makes use of VS extensibility to analyze only the files contained in C# projects in currently opened solution. The idea behind it is as follows: if you have an analysis violation, you should be able to fix that and then compile the code, and that can be done easily only for the current solution
2. Policy supports all flavours of C# projects in VS; I have tested most and am not aware of any unsupported projects at this time. Any feedback welcome!
3. Current version of the policy displays every analysis violation as separate check-in policy failure; however, it does not support easy navigation between policy failure and source code that caused the violation. This is the big must have feature for the next release

And talking about the next release, I am hoping to move source code to CodePlex, so it would be more easily available for modifications. Right now, if you have patches be welcome to send them in.

Related posts:
- StyleCo 4.3 Checkin Policy available
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

StyleCop 4.3 Checkin Policy available

In addition to recent release of StyleCop 4.3, Jason Allor has just released the documentation for extending StyleCop with custom rules (aka StyleCop SDK). CHM file contains information on writing custom rules, integration of StyleCop into build process and API reference.

Since new version of StyleCop includes many bug fixes as well as new rules and in the spirit of documented SDK available, I have updated the check-in policy for StyleCop 4.3. The changes include mostly namespace changes (to StyleCop from SourceAnalysis) as well as couple of fixes.

Please note that version 1.1 of policy is not compatible with the previous version; you will have to uninstall old version and reconfigure the Team Projects accordingly.

You can get either MSI installer or the source code. Both the compiled version and source code are provided AS IS with no warranties of any kind.

Related posts:
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

Getting Latest in VS2008 (addendum)

One thing I did not describe my previous post is the actual user experience in VS IDE. So as a footnote, it is worth to note that when get latest is performed as part of check out (due to either VS IDE or Team Project settings), you will be presented with the following dialog:

The good part of it is that now you are aware of what is happening; the bad part is that you cannot cancel and having additional dialog pop up is somewhat disruptive.

Two flavours of “Get Latest On Check-out” in VS 2008

While in TFS/VS 2005 there was no option to get latest on check out, in 2008 version there is not one but two different ways to configure that feature (Disclaimer: I am not endorsing getting latest on check out but just trying to reach sort of closure of TFS/VS 2008 featureset).

First option is to enable this setting per workstation, using Visual Studio TFS source control provider settings (available through “Tools->Options” menu):

This option is fully controlled by the user in his environment, and does not affect other users in any way.

Second option is to configure “Get Latest On Check-Out” per Team Project (using “Team->Team Project Settings->Source Control” menu):

Since the option is set for the Team Project, it can be enabled by the administrator and will affect all users working with the project files.

Thus in VS 2008 one has a choice of having “Get Latest On Check-out” option enabled either for all developers working at the project (using Team Project settings) or a developer can enable that option for himself (by using VS Source Control provider settings).

From the “best practices” standpoint, I’d like to note once again that getting latest on check-out is very disruptive, evil and outdated practice. While I am highlighting those features, I am neither a fan or a user of those.

Consider the following typical scenario – you have checked out file in VS project. Since get latest is performed, you just got yourself the latest version of that file. If that latest version contains changes that are incompatible with the other files’ versions in your workspace (say, dependencies on new interfaces that are not yet in your workspace), then you are screwed. That is, to make things tick now you will have to get latest versions of all relevant files in your workspace (hello and welcome back, VSS!).

And besides, Team Project setting somewhat smells of dictatorship, since it will force everyone on team to conform to VSS-like mode of operation. Not a good thing in today’s flexible world.

Related posts:
- Get latest on check-out in TFS 2008
- (Not) getting latest on check out – a bug?

Editing files in VS2008 SP1

As a follow up to a previous post on file handling in VS2005/VS2008, I thought it is worth to mention another big difference coming as part of VS2008 SP1.

Pre-SP1, if you edit a source controlled file that is not a part of currently loaded solution, VS will not prompt you to check out this file (and will not check it out automatically, if that is what you configuration settings).

However, if you work with files in Source Control Explorer in SP1, your experience will be pretty much identical to Solution Explorer experience, even if the file is not part of the current solution. That is, editing file will check it out the file (if that is your VS settings – Source Control Explorer behavior is defined by the same set of settings as Solution Explorer; namely, “Tools->Options->Source Control->Environment” tab).

Together with the change mentioned in my previous post, this small tune-up should significantly decrease the number of local changes that never made it up to the repository (that is, if you are tweaking files locally and modify them out of solution context).

Review Code Metrics your way – in Excel

In addition to filtering function, there is another (almost magical) function in Code Metrics tool window – “Export to Excel”. If you feel more comfortable reviewing numeric data in Excel, or the number of results in code metric calculation is very large (which easily happens even for middle sized projects), you just click on magic button on the Code Metrics window toolbar, and voila! Your results are available in Excel spreadsheet, with advanced sorting and filtering functionality, and graphs, and statistics …

And if you are Excel whiz, you can save historical results over the time and perform historical code metrics results comparison.

Enjoy!

Code Metrics Filter gotcha

A neat way to review Visual Studio 2008 code metrics results (and for large projects the list may become pretty large) is to use built-in filter functionality:

One may select any available column (Maintainability Index etc.) in Filter combo box, and specify Min/Max range. Additional neat feature of Code Metrics window is that all filter ranges applied are added to Filter combo box list, and thus can be easily reused:

The downside of this feature is that once you have applied several filters the combo box list can become pretty long. To remove the custom filters from the list one may clear certain registry entry value, viz. HCU\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\CodeMetrics key, value MRUList) (sorry for not finding more elegant supported way of doing it).

How to reuse FxCop projects in VSTS 2008

One pretty neat feature that is available out of the box in Visual Studio Team System 2008 static code analysis, is the ability to use FxCop project definitions to specify active rules for the analysis. That may be valuable if not all of the developers have VSTS licenses or in case where FxCop is the preferred vehicle for defining and sharing static code analysis rules.

To use FxCop project rules definitions in VS project, add the following two properties to relevant C#/VB.NET projects:

<RunCodeAnalysis>true</RunCodeAnalysis>

<CodeAnalysisProject>MsRules.FxCop</CodeAnalysisProject>

<CodeAnalysisRuleAssemblies>""</CodeAnalysisRuleAssemblies>

This properties specify that

• Static code analysis should be performed (RunCodeAnalysis)
  
• FxCop project file should be used for the rules definitions instead of in-project definitions (CodeAnalysisProject)
  
• No additional rule assembles should be used, since FxCop project already specifies the rules libraries (CodeAnalysisRuleAssemblies)

The properties will be used in CodeAnalysis.targets file (located at "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\CodeAnalysis\Microsoft.CodeAnalysis.targets" where MSBuildExtensionsPath32 usually is "C:\Program Files\MSBuild" folder) by RunCodeAnalysis MSBuild target. RunCodeAnalysis target invokes CodeAnalysis task that is responsible for actually running code analysis (and the values for the properties you have defined are passed to the task).

If you use that approach make sure that FxCop project provided in CodeAnalysisProject property does not have any targets defined inside; and don’t forget that all rules defined in VS Project Properties now do not represent rules executed in code analysis.

It is possible to achieve similar result in VS 2005, but that requires modification of Microsoft.CodeAnalysis.targets file (because while CodeAnalysis tasks has the same parameters in VS 2005/2008, those parameters are exposed only in VS2008).

There is another useful MSBuild property available in VSTS 2008 (for clarity named CodeAnalysisTreatWarningsAsErrors); have a look at this post at FxCop blog for details.

Source Analysis For C# Checkin Policy

It is a long weekend in US – and what do the geeks do on a holiday? They write code!

So here is my Sunday Night Live Source Analysis For C# Checkin policy (that uses Microsoft Source Analysis engine released several days ago to perform actual analysis). You can get either MSI installer or the source code. Usual caveats (both the compiled version and source code are provided AS IS with no warranties of any kind) apply.

Once you install the check-in policy using MSI above, you are set (since it includes required assemblies from Source Analysis distribution). Only prerequisite is VS 2008 with Team Explorer installed.

Now, when you define check-in policy for Team Project, you will be prompted to define Source Analysis rules to verify on check-in (in a fashion similar to Code Analysis policy). The policy will work only with C# files you check in that are part of the projects included in the active solution; if you have no solution, or the files are not part of the current solution, the policy will fail with appropriate error.

If all C# files are contained in the current solution, Source Analysis will be run on the files before check in; if it fails the policy will fail (double clicking on the failure message will display detailed dialog).

If you want to run Source Analysis on your projects with same definitions as are in the checkin policy, you will have to have Settings.SourceAnalysis file with the appropriate definitions in your project's folder. The policy does not create those files for you; however, when you check in and the policy is evaluated, the file with Source Analysis definitions will be created in the solution folder (named "<solution name>.sln.SourceAnalysis"). This file may be used to enforce same set of rules as in the policy for separate projects analysis.

I have tested the policy with stock C# projects (such as class libraries or executables); but my guess is there may be two-three bugs still hanging around the code. Drop me a line saying how helpful (or how buggy) it is at eugenez_at_attrice_dot_info.

Update: If you are wondering how I know about these Settings files, read all about it and how to use Source Analysis settings efficiently at Source Analysis team blog

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!

Microsoft Static Code Analysis tools survey

February issue of TFS Times newsletter is out; and this time I am personally involved since it contains a short bit I did on Microsoft Static Code Analysis tools in Visual Studio 2005/2008. Read that online or get the PDF version here.

Update: There is mirror for the article available here.

Building VS2008 projects in VS2005

Today I got reminded of one issue, that I did not mention in the previous post on VS2005 solutions and projects conversion to VS2005 (mostly because I was not aware of that at the time :).

As it is .Net projects created in VS2005 can be built both in 2005 and 2008 without any changes to the project file. However, should you create a new project in VS2008 (even one targeting .Net 2.0), you will not be able to build it in VS2005. The reason is that VS2008 project is created compliant with MSBuild 3.5, in which $(MSBuildBinPath) property (location of all system target files) is deprecated, and $(MSBuildToolsPath) is used instead. Thus VS2008 will use MSBuildToolsPath to specify the location of Microsoft.CSharp.targets file, and the project will promptly blow in VS2005 on build.

As far as I know, there is no elegant solution to this problem (short of changing the project file). Probably the easiest solution would be to create the projects in VS2005 (that is, if you want to have .Net 2.0 projects that can be opened in both versions of Visual Studio). If you do modify the project files, here is the snippet I use to make sure that the project can be built in both flavours of Visual Studio:

<!-- VS2008 original import (sans condition 

     which is added for VS2005 benefit) -->

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" 

        Condition="$(MSBuildToolsPath) != ''" />

<!-- VS2005 import - added for VS2005 compatibility 

     (since there is no ToolsPath there) -->

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" 

        Condition="$(MSBuildToolsPath) == ''" />

Footnote: once you decide to use .Net 3.5 in your project on VS2008, then obviously your project wont build in VS2005 no matter the modifications.