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

TFS Destroy – friend or foe?

While everyone else is blogging about VS 2010 Beta 2, I thought it still may be worth publishing this post that talks about VS 2008 behavior (yes, the old release ;).

One of the features missing in VS 2005 and added in VS 2008 was destroy command; people wanted to get rid of the source control artifacts for good and were unable to do so.

Interestingly, once the command become available it did not become too popular. Come think of it, there are very few cases where one can afford permanently deleting data; after all, source code is most valuable asset any software company has.

But should you decide on using destroy command, there are few important points to keep in mind:

1. Before executing destroy command, you might consider deleting item first. Leaving the item in “quarantine” while deleted for a week or so makes sure nobody uses the item (for example, as part of automated build) will miss it once it is completely gone. And once you are ready to delete it, use /preview switch to double check what files you are going to permanently wiped out

2. If you use destroy, destroy all versions of the item and do not fall for /keephistory option (with or without /stopat flag):

tf destroy $/Project/FolderOldName;C123 /stopat:C156 /keephistory

This option would destroy all (or some as in example above) versions of the item while retaining item’s history. It may be tempting to clean up database from old revisions leaving the history intact; the problem with this usage is that you will not be able to distinguish the revisions deleted when viewing the item’s history. That may lead to the following message when trying to view seemingly valid history:

3. When you execute destroy command, data is not deleted from DB immediately. There is TFSVersionControl Administration job running on TFS Data Tier at scheduled interval that takes care of actual DB purging. You can trigger the job run immediately by using /startcleanup option (or running on SQL Server manually). The job does not take care of cleaning up the warehouse,  it will get updated at warehouse processing scheduled intervals.

On a personal note, my usage of destroy was limited to removing sample & test TFS projects content; I never was able to get enough justification to permanently delete source code, however unused it may be. But your mileage may differ – if you do decide to get into destruction business, there are couple of very useful resources on TFS destroy that are not immediately discoverable through simple search; summary MSDN article and screencast How Do I: Use the TF Destroy Command in Visual Studio Team System 2008? by Richard Hundhausen.

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

Back To Future - Short File Names in TFS

Today I got reminded of something that I wanted to write about quite a while ago (when TFS 2005 was all the rage).

If you have legacy projects, chances are you have some DOS-style 8.3 file names. Not that there’s anything wrong with that... However, you might hit a problem when you start putting these files into TFS. That is, if you have certain file (say parameters.xml) under source control, and have another file with short file name (i.e. parame~1.xml) under the same folder – then you have a problem, since TFS 2005 will become confused when you get files from that folder (that’s how I know about these SF names – in my case there was a file and a subfolder with the same short name). There is wonderfully explicit knowledge base support article (KB 947649) on the topic.

Interesting fact that I did not know before today is that in TFS 2008 you will not have that problem anymore, since you will not be able to add SFN files. However, the data that already is in the repository can still exhibit the weird behavior.

Now, you are going to say that the scenario described above is extremely rare occasion. Yes, it is and this is a good news. But if you have some legacy DOS 8.3 file names stored up in VSS, conversion from VSS to TFS 2008 will not work now, since the short file names are not supported anymore. There is workaround for that described in another wonderfully explicit knowledge base support article (KB 951195).

And finally, there is a whole lot of useful (if a little bit outdated) information on Microsoft Support [make a note to check there often for 2008 stuff].

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

Renaming Team Project in VS2008 – nothing changed

Surprisingly, one of most popular posts on my blog is the one about renaming Team Projects. As it was written for VS2005, I thought I’d review it as of VS2008 SP1.

As it turns out there is not much to review. You still cannot rename the Team Project in VS2008, however there are several changes as to what can be deleted as of latest version of TFS:

• Work items now can be deleted (use destroywi command of TFS Power Tool), so once you move work items you can delete old ones
• Version control artifacts can be removed – fully or partially (partially by removing the contents while retaining the history) using destroy command with tf command-line client

Additionally, it is worth to note that work item moving tool by Eric Lee is available at CodePlex (it is not easy to find unless you know it is there).

Overall, the initial recommendation still stands: make sure you name Team Projects appropriately since it is a lot of pain to get close to renaming them (and is impossible to perform “clean” rename).

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).

Editing writable files in VS2008

One interesting change of TFS source control provider behavior in Visual Studio 2008 is the handling of writable files.

In VS2005, if you make certain source controlled file writable locally, editing it will not cause check out (you will have to explicitly check the file out); of course that assumes that VS is set either to explicitly or automatically check out file on edit or save.

With the same VS settings in VS2008, you will still be prompted to check out the file, even if it is writable. TFS source control provider tracks all controlled files in the solution, regardless of their read-only status.

The rational behind this change is clear – changing files locally without referencing source control repository may lead to changes never propagating to repository at all (and thus problems of “I have changed the file and it was not checked in” kind may arise).

However, there are some interesting problems you might encounter with that new behavior. Let’s say certain file is locked by someone else (with exclusive check-out lock). In VS2005 you would make this file writable locally, and VS would be happy to let you edit the file. In VS2008, however, VS will first check the status of the file in source control, and seeing that it is locked won’t allow you to edit this file.

There is workaround to this (aside from not ever messing up with local files modifications :); “Tools->Options->Source Control->Environment” tab in Visual Studio may be used to tweak the options. Setting checked-in items “Editing” behavior to “Do nothing” will allow you to edit file regardless of its status in source control (setting “Saving” behavior to “Save As” will allow you to save it). But keep in mind that this setting is probably very unproductive choice for day-to-day work.

Thanks for this tip go to Richard Berg.

Advanced workspace cloaking in TFS 2008

I stand corrected (thanks Richard!); there are two new workspace mapping features available in TFS 2008: wildcard mapping and root level cloaking.

The advanced cloaking schema supports scenario where the high level folder is cloaked, and some of the sub-folders are explicitly mapped. It is useful in the scenario where you need contents of one folder out of say, hundred (alternative would be to map high level folder and cloak ninety-nine sub-folders).

The application of this mapping schema is somewhat tricky (and initially it got me thinking that the feature ended up outside of the RTM version) – the cloaked folder must have higher level folder mapped.

That is the following will not work (displaying error “The item XXX may not be cloaked because it does not have mapped parent”):

tf workfold /cloak $/Project/Src /workspace:Test

tf workfold /map $/Project/Src/Bin c:\Project\Src\Bin /workspace:Test

To make it work you need to have the following setup:

tf workfold /map $/Project c:\Project /workspace:Test

tf workfold /cloak $/Project/Src /workspace:Test

tf workfold /map $/Project/Src/Bin c:\Project\Src\Bin /workspace:Test

In this last example, recursive get latest in Test will get all files and sub-folders under $/Project, except for $/Project/Src sub-folder. This sub-folder will be cloaked and only files under $/Project/Src/Bin will be retrieved.

Wildcard workspace mapping syntax in TFS 2008

Just a footnote on workspace mappings in TFS 2008 – while initially there were couple of features planned for Orcas release, only one feature has made it into RTM. Correction: both features are available, see this post discussing the second feature.

In TFS 2008 it is possible to map only one level of the folder hierarchy using wildcard syntax

tf workfold /map $/Project/Source/* c:\src\Project /workspace:SampleWorkspace

The mapping above will map only one level of files and folders under $/Project/Source and will not retrieve files contained in sub-folders.

This syntax is nice to have, though I am not sure how useful it is. The same effect can be achieved by using cloaking on sub-folders (though of course wildcard is much more elegant way).

Detecting TFS Server version from 2008 client

With the release of VSTS 2008, in certain configurations you might want to detect what version of the server your client runs against, the important configuration being 2008 client vs. 2005 TFS server, since in that configuration the feature-set on the client will be more restrictive (2005 client against 2008 server is no problem as it will not use any new features anyway).

It turns out that to get this bit of information your best bet is to use Team Build object model (the advise is courtesy of Aaron Hallberg):

IBuildServer buildServer = 

    teamFoundationServer.GetService(typeof(IBuildServer)) 

     as IBuildServer;

if (buildServer.BuildServerVersion ==  BuildServerVersion.V1)

    ; // server is 2005

else if (buildServer.BuildServerVersion == BuildServerVersion.V2)

    ; // server is 2008

If you think about it for a second, it sort of makes sense, since Team Build is the component that differs most between TFS 2005 and 2008 versions. So in the absence of general service versioning model one can use that for determining the server version.

And if you did not know it yet, Team Build object model was greatly enhanced in 2008. One of the recent discoveries for me was the custom properties bag available for builds build types in Team Build 2008 (as described in Aaron Hallberg’s blog). Using the custom properties one could provide custom categories for build types(and perhaps even expose them in Team Explorer). This is something I am planning to take a stab on (if time allows).

For Team Build OM intro there is a detailed post by Martin Woodward (it even has class diagram drawing!); and you can download the whole documentation here.

Updated: Unfortunately, it appears that custom properties I was so enthusiastic about are available for builds only, not for the build types. Thanks to Ed for correction!

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!

Check out TFS Times March edition

Just a footnote - in March edition of TFS Times, check out two articles by yours truly: "Check in policies survey" and "Exploring Attrice Team Foundation Sidekicks". If you prefer a PDF version, download one from here.

New TFS releases - in time for holidays

If you happen to have some leasure during holidays, you might want to check out the following:

• VS2008 and TFS2008 trial VPC (to expire in April '08). You are looking at approx. 4.5 Gb in 7 parts.


• TFS2008 only trial VPC (also to expire in April '08). You are looking at approx. 2.5 Gb in 4 parts.

While those VPC rock, one small note - the TFS server is completely bare (that is you should expect to spend some time to setup projects, build etc. if you are going to use those VPCs for demo).
And they do not have new TFS Power Tools pre-installed. What, you have not heard about it? Yes, you should download VS2008 version of Power Tools. My favorites in this version are files and status search (for all ye SourceSafe faithful, it is very similar to VSS operation - allows one to search by file name and file status) and quick label (allows labeling of the selected files/folders in one click).
And that's not all! There is also new version of MSSCCI provider for your to download!
Check Brian Harry's blog for more information.

And Happy Holidays to all! See you in 2008!