2014-03-05

Book Review: Resharper Essentials - Or: Find your way around Reharper's Shortcuts

I received an ebook copy from Packt Publishing for an honest review, So here we go :).

I've been a long time, on and off user of Resharper. But it has taken me a long time to learn most of its features. Even today I still find little gems I never kew existed, it's like Visual Studio itself, which has so many features I've never even seen before.

This book quickly takes you through the most important feature area's of Resharper and teaches you the most important shortcuts. Ctrl-T, Ctrl-R, Ctrl-U, Alt-Enter, Alt-` and (Ctrl-)Alt-Ins. With those few key presses and an idea what they do you'r probably able to unlock all the hidden potentials of Resharper by paying attention to what is shown on your screen. Without those you might not even know what Resharper can do for you. The book showed me a few thing I didn't even know existed :).

2014-03-04

Codelens features and Visual Studio versions

If you're as happy with the new CodeLens features in Visual Studio 2013 ultimate as I am, you've probably found out that some of the features rely on server side features. This means that some Code Lenses only work when you are connected to the latest version of Team Foundation Server (2013). 

Even Visual Studio Online doesn't (yet) support Code Lens. The background processing it introduces on the number of Visual Studio Online accounts that are currently active on the service is not something that should be taken lightly. Given the tremendous value of Code Lens, I expect the server dependent lenses to be enabled in the months to come, there is a UserVoice suggestion you can track for this item.

Another area where certain Code Lens features are not yet available is when you're using a Git repository. There is an open UserVoice suggestion for this and again, given the popularity of Code Lens, I expect support to be added in the future. Since with Git the whole commit history is available on your local system, it will probably even work when you're not connected to the remote TFS repository.

CodeLens is currently only supported when editing C# and VB.NET. C++ (managed and unmanaged), Javascript, TypeScript and F# or any other file format are currently not supported.


LensTeam Foundation Server versionVisual Studio Online 3rd Party
≤2010 2012 2013
TFVC Git TFVC Git
Test Status**yesyesyesyesyesyesyes
Referencesyesyesyesyesyesyesyes
Tested By**yesyesyesyesyesyesyes
Authorsnonoyes*nononono
Changesnonoyes*nononono
Bugs update 1nonoyes*nononono
Work Items update 1nonoyes*nononono
Code Reviews update 1nonoyes*nononono
Code Health add-onyesyesyesyesyesyesyes
Incoming Changes update 2yesyesyesnononono
Intellitrace update 2???????




* Works only when connected to your Team foundation Server.
** Supports MsTest, XUnit (requires latest adapter version) and NUnit.

If you have an idea for a new Code Lens, please submit your suggestion here.

I will update this table when new Lenses appear or when new Lenses are enabled on another Server, Source Control Repository or on Visual Studio Online.

2014-02-17

Ask a developer for confirmation in a TFS checkin policy

A TFS checkin policy can normally only be dismissed by overriding the policy. There is no way to selectively allow a user to override one, but not another policy. And there is no way to interact with the user from the Check-in dialog using custom UI other than the message, you can't add your own check box or text box.



One of the policies I recently wrote warns the developer that he might be doing something stupid. We want our developers to be able to dismiss this warning, but we don't want him to override the work item attachment or the comment policy.

So we decided to add a way for the developer to dismiss the warning by double clicking the message.

Edward Thompson confirmed on StackOverflow that interacting with the user on the Evaluate method to be avoided. But the documentation mentions another event, the Activate method, which is called when the user interacts directly with the warning.

This is ideal for this situation. By double clicking the warning, we trigger the Activate method, show a warning and upon dismissal of the dialog save the result.

Now when the conditions for the policy changes, we reset the result and the policy will trigger again.

In order to allow a user to dismiss the policy, we added a configuration option to the policy which will allow this:


A sample UserOverridePolicy can be found on StackOverflow and our Multiple Branches policy implements this strategy as well.

I might even take this as far as allowing any policy to be nested in a generic UserDismissablePolicy in the future, similar to how the Custom Path Policy works.

Source: StackOverflow

2014-02-10

2014-01-31

Creating a Check-in Policy to warn when checking into multiple branches at once

Update: Project has been uploaded to GitHub.

One of the teams I work with recently had strange issues when they tried to merge their feature branches to the main branch. It turned out that one developer had accidentally misconfigured his workspace and was check-in in half of his changes in a solution in one branch and the other half of his changes into another. Looking at the version history things like these happened in the past as well and explained some of the issues they had been experiencing.

The team has learned it's lesson, but to prevent these kind of accidents in the future we're creating a check-in policy that flags a warning to the developer that he's doing something that is potentially dangerous.

The policy itself is very simple to build. Follow one of the existing walk-throughs to create the project  and make sure you use the correct CLR and TFS Client Object Model assemblies for your target visual studio version.

A check-in policy has an Evaluate method, which is where all the magic happens. To make sure you're only checking into one branch at a time, we request the BranchRoot objects and compare it against the server path of all the items selected to be checked in:


public override PolicyFailure[] Evaluate()
{
    if (PendingCheckin.PendingChanges.AffectedTeamProjectPaths.Length > 1)
    {
        return new[]{new PolicyFailure("Checking into multiple projects at the same time", this)};
    }

    var branches = this.PendingCheckin.PendingChanges.Workspace.VersionControlServer
        .QueryRootBranchObjects(RecursionType.Full);

    var groupedChanges = PendingCheckin.PendingChanges.CheckedPendingChanges.GroupBy(
       change => branches.SingleOrDefault(branch => change.ServerItem.StartsWith(branch.Properties.RootItem.Item)));

    if (groupedChanges.Count() > 1)
    {
       return new[]{new PolicyFailure("Checking into multiple branches at the same time", this)};
    }

    return new PolicyFailure[0];
}

I've placed the solution onto GitHub and might add a vsix at some later point.

Creating a custom check-in policy pack that works with multiple versions of Visual Studio.

Anyone who has ever tried to create a custom check-in policy for Visual Studio probably knows that the policy isn't specific to the TFS server version you're using, but to the version of Visual Studio that is connecting. This can be confusing for companies that are upgrading their Visual Studio, but not their TFS installation (or for people who've moved to Visual Studio Online).

You might be able to get away with using Binding Redirects in the Visual Studio ..config file (and in the .config file of any other process that might invoke the policy) as documented here. This essentially tells .NET to load a newer version of a dependent assembly and will trick your policy that was created for an older version of Visual Studio to load in a newer one. You cannot use this trick to load a policy created for a newer version of Visual Studio in a older version.

The official way to resolve this, is to create a different binary for each Visual Studio Version and register that binary in the corresponding config hyve.

Each of these projects will be very similar and in many cases you can reuse the same .cs file for each version of Visual Studio (as long as you're not using any API that was introduced in a later version.

Step one, is to create the right projects:

Visual Studio Project Type CPU .NET Version TFS OM Version Visual Studio Version
2013 Class LibraryAnyCPU 4.5 12.0.0.0 v12.0
2012 Class LibraryAnyCPU 4.0 11.0.0.0 v11.0
2010 Class LibraryAnyCPU 4.0 10.0.0.0 v10.0
2008 Class LibraryAnyCPU 3.0 9.0.0.0 v9.0
2005 Class LibraryAnyCPU 2.0 8.0.0.0 v8.0

Step two is to add the right references to it;

From the Visual Studio installation directory find:
  • Microsoft.TeamFoundation.VersionControl.Client.dll
  • Microsoft.TeamFoundation.Client.dll
  • Microsoft.TeamFoundation.dll
You can find these in: C:\Program Files (x86)\Microsoft Visual Studio {VisualStudioVersion}\Common7\IDE\PrivateAssemblies\.

Step 3, is to add a new class to it and have it inherit from PolicyBase.

Step 4, mark the class as [Serializable()].

If your code doesn't use any special features of the more recent versions of the Client Object Model, you can use "Add As Link" to add the same .cs to all the projects you've created in your solution.

Step 5 to each project add a compiler constant for the visual studio version you're targeting. This allows you to use #IF (VS2010) #ENDIF to add Visual Studio version specific code.

Now you're set to implement all the abstract methods of the PolicyBase class.

When you've implemented your policy you need to deploy it to all of your clients. This can either be done using a MSI, a VSIX, the Power Tools or manually. The key thing is to deploy the policy assemblies to the client and then adding a registry key to register your policy. Make sure you register for each version of Visual Studio by substituting the correct Visual Studio Version.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v12.0\\JesseHouwing.CheckinPolicies.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v12.0\\JesseHouwing.CheckinPolicies.dll"

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\12.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v12.0\\JesseHouwing.CheckinPolicies.dll"

2014-01-28

One of my new favorite plugins for Visual Studio and TFS

Today I stumbled upon a new Team Explorer extension for TFS in Visual Studio. It almost immediately
made it on my shortlist of things that I need to have on every Visual Studio installation. It's simple, but brilliant.

Ok, enough praise :).

This extension nests itself into Team Explorer and adds a Merge button there. Upon selection of the source and target branch it will automatically list all Change Sets that need merging and when you merge them it automatically associates the correct Change Sets and Work Items. The latter is exactly why I instantly fell in love.

The extension is available for both Visual Studio 2012 and 2013.