CodeOpinion

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Code Reviews with Visual Studio

January 22, 2015January 22, 2015 Derek Comartin Leave a comment

Code reviews are one of the most important development practices to improves quality, reduces bugs, and knowledge sharing. Here is how to perform Code Reviews with Visual Studio.

In order to use code reviews with Visual Studio, you must be using TFVS (Team Foundation Version Control) within Visual Studio Online or Team Foundation

Request Code Review

Before you commit your changes, in the team explorer go to the My Work section. Create your code review request by specifying the reviewer (who you want to perform the code review), title, area path, and description.

After submitting the code review request, you can suspend your current work while you wait for feedback from the code reviewer. This allows you to begin work on another product backlog item.

Perform Code Review

Once a code review request has been sent to you, you can see it from the My Work section.

Opening the code review will show you the files modified so you can review with the standard diff view. You can add comments to each file change to let the author know of any suggested changes.

Resume Work and Review Feedback

Once your code has been reviewed, you can resume your suspended work and view the feedback from the code reviewer.

Get Notified!

Once you start using the above workflow, you may want to get notified via email when someone sends you a code review request. To do so from Visual Studio, in the Team Explorer access the Settings section.

This will open up Visual Studio online in your browser where you can manage your basic alerts.

Add a build number to your Assembly Version

January 15, 2015January 15, 2015 Derek Comartin Leave a comment

Including the build number in your assembly version number can be a very useful feature. Using reflection you can retrieve you assembly version number and display it appropriately in your app. Here is how to add a build number to your Assembly Version using TeamCity continuous integration server.

AssemblyInfo Patcher

TeamCity is a continuous integration server developed by JetBrains. If you are looking at trying a new build server, I highly recommend giving it a try. It should take no longer than a hour or two to install, configure, and build your project.

There is a built-in build feature that allows you to modify the AssemblyInfo.cs during the build process. This feature works by scanning for all AssemblyInfo files (.cs, .vb, .cpp, .fs) in their usual file locations and replaces the AssemblyVersion, AssemblyFileVersion and AssemblyInformationVersion attributes with the values you define.

Add Build Feature

Under your build configuration settings, add a new Build Feature.

Select the AssemblyInfo patcher. Here you will be able to specify the version format by using parameters or static text. In my example below, I’m including the %build.counter% parameter in the version format.

That’s it! After the build is complete, the assembly outputted now contains the file version with build number.

Visual Studio Online Check-In Policies

January 8, 2015January 8, 2015 Derek Comartin 1 Comment

Want to produce better code and more efficient development group? Start using Visual Studio Online check-in policies within your team project.

Check-in Policies are rules you can define at a Visual Studio Online team project which are enforced when a developer attempts to check-in their source code.

Note: You must be using Team Foundation Version Control (TFVC) with your project in order to use the check-in policies. Although VSO now supports Git as a version control system for your team project, check-in policies are not supported.

One of the main reasons I started using check-in policies was to enforce associated work items to a changeset. Having all changsets associated to work enabled me to automate the creation of a change lot during the build process. If you are looking for better way to visualize your Visual Studio Online work items, take a look at my LeanKit Visual Studio Online Integration blog post.

Source Control Settings

From the Team Explorer, access the settings menu and select Source Control under the Team Project heading.

Under the Check-in Policy tab, click the Add button to select the policy you want to add.

Without any extension or power tools, Visual Studio Online provides four team project check-in policies that you can specify:

Builds
Requires that the latest build was successful for each affected continuous integration build definition.

Changeset Comments Policy
Requires the developer to provide comments with the check-in. These comments will be associated with the changeset.

Code Analysis
Requires the developer to run Code Analysis from Visual Studio prior to check-in.

Work Items
Requires the developer to associate at least one work item with the check- in.

Code Review Policy

There is a great policy written by Colin Dembovsky (@colindembovsky) on Visual Studio Gallery that provides Code Review Policy.

Once the extension is installed you will now have a new option available to add.

Once this policy is added, you will be unable to check-in until a Code Review has been requested, closed, and has no “Needs Work” response.