Initializers for auto-properties

C#6.0 supports Read-Only auto properties. Please check the post here before reading this.

If you wanted a read-only property with default value then you had to create a private setter and then set the default in constructor.

1 public class Student 2 { 3 public string Name { get; set; } 4 public string Age { get; private set; } 5 6 public Student () 7 { 8 Age = 20; 9 } 10 }


Now, In C# 6.0 Property Initializer allows you to create a property with the default value without invoking the setter. It directly sets the value of the backing field.

1 public class Student 2 { 3 public string Name { get; set; } 4 public string Age { get; set; } = 20; 5 }

Here, the default value of property can be changed after creating an instance of the class. But, if you want to create read-only property with default value then you need to remove setter.

1 public class Student 2 { 3 public string Name { get; set; } 4 public string Age { get; } = 20; 5 }

With this Initializers for auto-properties feature, you don’t need to invoke the setter to initialize the default values anymore.

Getter-only auto-properties in C# 6.0

C# 6.0 allows the definition of read-only auto properties which means it supports getter only method.

Automatic properties were first introduced in c# 3.o. It allowed us to create a class with getters and setters.

1 public class Student 2 { 3 public string Name { get; set; } 4 public string Age { get; set; } 5 }

But, in case we needed to create a read-only property then a setter method marked private.

1 public class Student 2 { 3 public string Name { get; private set; } 4 public string Age { get; set; } 5 }

But, “private set” was not the same as “read-only”. The private keyword makes the visibility of the setter available to the class itself. It means other objects cannot use the setter, but methods of the same class can call it. This makes clear that the private set isn’t read-only in the true definition.

What’s new in C# 6.0

C# 6.o introduced many small but useful features. Here’s the list of new features.

  • Getter-only auto-properties
  • Initializers for auto-properties
  • Using static classes
  • String interpolation
  • Expression-bodied methods
  • Index Initializers
  • Null-conditional operators
  • The nameof operator
  • Exception Filters
  • Await in catch and finally

I will share more details about all the new features in next few posts.

CodeLens feature in Visual Studio 2013

CodeLens is a new feature in Visual Studio 2013 ultimate, it displays useful information about the code directly inside code editor. The information it displays includes method references, tests associated with a method, code history, associated bug etc. To get the same information without code lens, users have to dig through several windows which takes away from writing code.

By default, Code Lens feature is enabled in Visual Studio 2013 Ultimate. To modify the settings of CodeLens, users have to go to Tools –> Options –> Text Editor —> All Languages –> CodeLens. Here, users can either turn on – off complete Codelens functionality or specific pieces from the available list.


Some of the CodeLens features don’t work with previous versions of Team Foundation Server. Here’s the CodeLens feature matrix for different versions of Team Foundation Server.

Lens TFS2013 GIT TFS 2012
Test Status yes yes yes
References yes yes yes
Tested By yes yes yes
Authors yes yes no
Changes yes yes no
Bugs yes yes no
Work Items yes yes no
Code Reviews yes no no
Incoming Changes yes yes yes
Intellitrace yes no yes

Currently, CodeLens is supported only when editing C# and VB.NET.

CodeLens indicator sample:

For example Tested By indicator shows the tests available for a particular method. In below figure, it shows that there are two tests available for the method, and none of them have been executed.


Clicking the link displays the tests, and it also allows users to run a specific test or all tests related to the method. Users can click the Run All link to run all the associated tests. Below fig shows the results, with one test passing, and the other test failing.


CodeLens provides useful information without getting in the way or becoming distracting. The ability for a developer to stay in the code editor while receiving detailed information from multiple parts of the codebase and Team Foundation Server is definitely a useful feature.

Code Review feature in Team Foundation Server

Team Foundation Server 2012 and later versions provides in-built code review workflow feature. Code Review can be initiated either when user has some pending changes in workspace (before a Check-in) or after a check-in from change sets option.

Request a Code Review before check-in: A Code Review workflow can be initiated for In-Progress work by clicking Request Review option under My Work tab.


Request a Code Review after check-in: Code Review can be initiated after a check-in by clicking Request Review option for particular changeset from history tab.


In both the above scenario’s, request review option will take the users to the New Code Review pane in My Work tab.


Here, the requester can add below items before submitting the review request.

  • One or multiple code reviewers
  • Title, Area Path and Description for the In-progress work

If user clicks Submit Request option, pending changes will be automatically shelved and the Code Review Request work item will be created. It’s assigned to the users mentioned in Add Reviewers field.

The reviewers will be notified if they have the email alerts configured for code reviews. If not, they can find the review requests assigned to them in Code Review and Requests section under My Work tab.


Reviewer can double click an item from the list to review the changes.


Reviewer can go through the changes in files attached to the particular review request and complete the review.

Once review is done, the reviewer can simply click Send & Finish to close the review and post feedback to the requestor.


After reviewer submits the feedback by clicking Send & Finish option, the status with comments will be available under requesters My Work tab.


My Work feature in TFS

A typical development workflow will follow below steps when connected to the TFS version control system.

  1. Open a project
  2. Make some changes
  3. Enter a comment describing the changes made
  4. Associate the work items related to the changes
  5. Check-in changes

This workflow holds well if user is working on a single task a time. But, it gets increasingly difficult to keep track of changes when working on multiple tasks at the same time. The new “My Work” feature addresses this problem, it gives users a place to review the work that’s currently assigned and keeps track of different tasks.

My work page will show all the To Do and In Progress tasks assigned to the user based on a work item query. If the user want to start the work on a To Do task then user can either drag n drop the task from To Do to In Progress tab or can right click the task and click the Add to In Progress option.


If user haven’t made any changes to the project, will see only “Finish” and “Suspend” options and no “Check In” option.


Once user make some changes to the project, will see different options.

  • Check In
  • Request Review
  • Suspend


The first option will check-in the changes to version control system and the second option Request Review will start the Code Review workflow. The last option Suspend will move all the changes to a shelveset and the changes are undone from user workspace.


At this point, user will have a very clean looking workspace and he can start the work on another task either by moving a To Do task to In Progress tab or clicking Resume option on existing suspended work.

The Suspend option captures all IDE state including files, tool windows, bookmarks, breakpoints, etc so that user can return exactly to the same state later. This feature significantly decreases the delays caused due to switch contexts and interruptions.

TFS on Azure IaaS guide shipped

ALM Rangers team has shipped v1.4 release of TFS Planning guide and this release focuses on TFS on Azure IaaS scenarios. It includes planning and setup guidance for the implementation of  Team Foundation Server on Azure Infrastructure as a Service (IaaS).

This project has five guides in total, out of which one is TFS on Azure IaaS main guide and the other four are supplement guides to cover the additional scenarios.


Below listed are the scenarios covered in additional guides.

  • Build Services
  • Proxy Server
  • Exposing Data Tier
  • Extending Access

I had the opportunity to work on this awesome project. Huge thanks to all the team members who volunteered their personal time for this project.

Andrea Scripa, Chris Margraff, Clementino Mendonca , Dan Marzolini, Dave McKinstry, David Pitcher, Eric Golpe, Grant Holliday, Hassan Fadili, Jahangeer Mohammed, Jim Szubryt, Marcus Fernandez, Mario Rodriguez, Micheal Learned, Oliver Hilgers, Susan Ferrell, Tarun Arora, Tony Feissle, Utkarsh Shigihalli, Willy-Peter Schaub and Wouter de Kort.

Please download the guide from CodePlex site and let us know your feedback.

Update doesn’t apply or is blocked by another condition on your computer

You might come across this error when trying to install the Visual Studio quarterly updates.


This error usually occurs when none of the Visual Studio editions (Premium, Professional or Express) are installed and you are trying to install the Visual Studio quarterly updates.

When installing the updates, you need to make sure that you are downloading the right package. There are two kinds of update packages.

Visual Studio Update: It will only install the particular update. To install this update, you need to have the Visual Studio installed or else you will get the error mentioned above.


Microsoft Visual Studio with Update: This package will install the Visual Studio and the updates. To install this package, prior installation of Visual Studio is not required.


TF215097: An error occurred while initializing a build for build definition \project name\build definition name

Issue: TF215097 An error occurred while initializing a build for build definition \projectname\build definition name: Cannot create unknown type ‘{clr-namespace:BuildActivitiesLib.Activities;assembly=BuildActivities}Checkout’.

Solution: We have developed lot of custom build activities and usually upgrade them with our Team Foundation Server upgrades every major release. We recently upgraded to TFS 2013 and as part of build upgrade we have rebuild all the activities with latest version of Visual Studio, TFS Assemblies and .Net framework version. All the build controllers were pointing to TFS 2013 compatible custom activity binaries.

We started getting above error on a particular build server which is still running on Team Foundation Server 2012 build services. This server is not upgraded to latest version of TFS build due to the operating system limitation and we didn’t go for OS upgrade because TFS 2013 supports TFS 2012 build services.

But, looks like the custom build activity assemblies should match with Team Foundation Build Services version and not with the Team Foundation Server. We are able to resolve the issue with TFS 2012 build controller by changing custom assemblies path to point to TFS 2012 compatible libraries path.

TF400018: The local version table for the local workspace could not be opened.

Issue: TF400018 The local version table for the local workspace workspacename;username could not be opened. The workspace version table contains an unknown schema version.

Solution: This error usually occurs due to workspace getting corrupted especially when Local workspaces are configured. This error doesn’t allow you to view the source control explorer. To resolve this and to re-use the same workspace, you have to rename the $tf hidden folder which will be created at the root of your local workspace mapped folder.