Mehran Nikoo's Notes

Unshelving a Shelveset to a Different Branch in TFS

2009-07-07T13:53:00Z

[Note: In this post, I am assuming that you are familiar with the TFS Branching Guidance. If you haven't read the guide, I strongly recommend that you do so! I will be referring to the branch names suggested for the basic branch plan.]

Scenario: After an application is released to the production environment, a defect has been raised by the users. The production support team decides to fix this defect before the next version is released so they start by modifying the appropriate files in the REL branch to fix the defect. When the developer working on the defect finishes his job, he shelves those changes and asks the support team lead to review those changes before they are checked in. The support team lead analyses the changes and because of the risks involved, she talks to the users and they agree to wait until the release of the next version to get the fix.

Challenge: When you create a shelveset, the server path of each shelved file is stored with the shelveset so when you try to unshelve that shelveset, the files in the same branch are modified. You cannot unshelve the shelveset to a different branch such as DEV so you will need to do this manually by unshelving to the original branch and then manually copying the modified files across, which is time consuming and error prone.

Solution: TFS 2008 Power Tools includes a command line tool (TFPT.exe), which allows you to perform advanced operations in TFS. One of these operations is the unshelve command, which allows you to change the server path of the files in a shelveset during the unshelve operation. This means you can use this command to unshelve any shelveset to a different branch. In our scenario, the shelveset was originally created in the REL branch so the development team can use the TFPT tool to unshelve the shelveset to the DEV branch.

So let's assume that the support team have changed the source files in the REL branch and we want to unshelve this shelveset to the DEV branch. In order to do this, we need to:

- Make sure the TFPT command line tool is installed!
- Go to the command prompt and change the folder to a location that is mapped in the desired workspace.
- Run the following command:

TFPT.exe unshelve ReleaseHotFix1 /migrate /source:$/MyProject/REL /target:$/MyProject/DEV

Where ReleaseHotFix1 is the original shelveset name and $/MyProject/REL and $/MyProject/DEV are the server paths to the REL and DEV branches respectively.

When you run the unshelve command with the migrate option, the tool will prompt you to choose which version of the file (in origin or target) you want to keep. It will also allow you to perform a file merge if needed, which will be done in the merge tool.

The following diagram shows the sequence of events that need to happen across multiple branches in our scenario:

Events:

S1: Production support team shelve their changes in the REL branch.
U1: Development team unshelve the shelveset to the DEV branch by running the TFPT tool and using the shelveset migrate option.
C1: After resolving any potential conflicts in the DEV branch, the modified files are checked in.
RI1: At some point, the checked-in changeset will be reverse integrated (merged) back into the MAIN branch.

Microsoft's Mega Data Centre in Dublin Now Online

2009-07-06T23:36:00Z

Windows Azure and some other components of the Azure Services Platform are expected to be commercially available later in 2009. Clearly, one of the key components required for reaching this milestone is the physical hardware, networking equipment and the supporting services such as power generation and cooling, something that we refer to as "Global Foundation Services".

On Wednesday last week (1 July 2009), a Generation 3 data centre outside the US was brought online in Dublin. This data centre will be used to host various services including Azure service hosting and additional live and online services. There is also another data centre in Chicago, which is planned to go online on 20 July. You can read more about this new development on Microsoft Data Centers Blog.

Spanish (United States) Locale

2009-06-29T10:09:00Z

Last week, I had a enquiry from a customer about the Spanish locale for the United States. As he mentioned, it does make sense to have this locale, especially for the users based in the southern regions of the US. If you are running Windows XP or Windows Server 2003, there is no such locale supported by the operating system so if you try to access this locale in a managed application by writing this line of code:

System.Globalization.CultureInfo cultureInfo = new System.Globalization.CultureInfo("es-US");

you will get an ArgumentException, which says: "Culture name 'es-US' is not supported". As a workaround, you can use the "es-MX" locale or create your own locale.

But the good news is that the support for the "es-US" locale was added in Windows Vista and Windows Server 2008 so if you are running one of these operating systems, you can now use the es-US locale (LCID = 21514) and the same line of code we used above will work fine.

This page has a complete list of the locale IDs assigned by Microsoft so if you thinking of creating your own locale, check this list first to make sure there is no conflict with the existing locales.

VSTS 2010 Beta 1 Available for Download

2009-05-18T19:06:00Z

As planned, VSTS 2010 Team Suite Beta 1, .NET Framework 4 Beta 1, TFS 2010 Beta 1 and VSTS 2010 Test Load Agent and Controller Beta 1 are now available for download from MSDN Subscribers area.

We now have 32-bit and 64-bit support for TFS and the TFS client OM. All of the client tools such as Visual Studio will continue to run in 32-bit environment though. For more information on the supported environments for TFS and the improvements in setup, administration and operations refer to Brian Harry's post.

VSTS Web Test Recorder Bar Missing in Windows Vista/7 64-bit

2009-02-19T21:28:00Z

Primarily for my own reference in the future but you may find this useful too. If you are running Windows Vista/7 64-bit and want to use the VSTS 2008 Web Test Recorder plug-in, the web test recorder bar may be unavailable due to the way Windows caches the list of available explorer bars. In order to resolve this, you can apply some tweaks to the registry. Michael Taute has a useful post which explains the problem and solution in more detail and covers some other issues too.

Project and File References Revisited

2009-02-10T10:18:00Z

Most .NET developers and architects are familiar with various approaches to Visual Studio solution design:

Single Solution

Partitioned Solution

Multiple Solutions

Multiple Partitioned Solutions

"What? Haven't heard of "Multiple Partitioned Solutions" before. Did you just make it up?"

Yes, you might be using it already but you didn't know what it's called. That's fine as I have come up with that name and haven't written about it before :) So please read on!

Most of the development projects contain more than one Visual Studio project. As soon as a second project is added to the solution, as a developer/architect, you start thinking about how the dependencies should look like.

Meet "Camp P"
Members of camp P believe file references are evil as they cause all sorts of versioning and build issues when the dependencies go out-of-date. The members of this camp try to put everything in the same solution and life is great as long as you can count the number of projects with your fingers. There has been a debate out there as to whether Visual Studio should become quicker when it comes to handling large solutions. This issue was partly addressed by release of Visual Studio 2005 SP1 where we introduced some performance improvements in the IDE. These improvements are also rolled forward to Visual Studio 2008. However, you need to take into account all the work the IDE and the compiler need to do while you are typing in the IDE to provide you with Intellisense and compiler warnings/errors. So at some point, you will hit a practical limit on the number of projects you can have open in Visual Studio.

Meet "Camp F"
This is where the members of "Camp F" are coming from. They want to avoid the project references in order to speed up the IDE but they usually end up spending the time they saved on resolving the versioning issues.

Now Meet Both!
None of these solutions are perfect but as long as the development team is consistent in following one of these approaches, then the team can live with it. This becomes a major problem when you have members from both camps in the same development team. This has been the case in most of the development teams I have worked with and I bet most of you have had similar experiences. So what is a typical day on such project? Somebody from "Camp F" is not happy with performance of the IDE while he is working on the "Order Processing" feature of the application. As a result, he decides to replace all of the references to the "UI Framework" projects with file references. But guess that? The dependency type is defined in the project file, so this change results in modification of the project file and the changes are checked back into the source control at some point. Few hours later, somebody from "Camp P" who is working on one of those "UI Framework" projects is trying to perform an integration test to validate a change she made to the UI Framework and finds out that the dependencies are out of date. She checks the source control as it was working fine until that morning and notices the change. She then reverts all of those changes as file references will make her job harder. And the team will soon end up in changing the references types back and forth between project and file references and and this changes cause further problems in the build process. Add to this all of the discussions/arguments as to which approach is better and you will see how much time is wasted as developers and build engineers keep changing the dependencies to suit their needs.

What is the solution then? I am going to start with re-iterating what you probably know already but bear with me - I'll try to keep it short!

The Team Development with Visual Studio Team Foundation Server guide does a pretty good job at providing high level guidelines for choosing the right approach. It provides three options for managing the solutions: Single Solution, Partitioned Solution and Multiple Solutions. I am going to skip over the Single Solution. If you can manage everything in the same solution, then you are not worried much about the solution design, right?

Partitioned Solution
If you work on a large system, consider using multiple solutions, each representing a sub-system in your application. These solutions can be used by developers in order to work on smaller parts of the system without having to load all code across all projects. Design your solution structure so any projects that have dependencies are grouped together. This enables you to use project references rather than file references. Also consider creating a master solution file that contains all of the projects. You can use this to build your entire application.

Multiple Solutions
If you work on a very large solution requiring many dozens of projects, you may encounter solution scalability limits. In this scenario, break your application into multiple solutions but do not create a master solution for the entire application because all references inside each solution are project references. References to projects outside of each solution (for example to third-party libraries or projects in another sub-solution) are file references. This means that there can be no “master” solution.

Instead, you must use a script that understands the order in which the solutions need to be built. One of the maintenance tasks associated with a multiple-solution structure is ensuring that developers do not inadvertently create circular references between solutions. This structure requires complex build scripts and explicit mapping of dependency relationships. In this structure it is not possible to build the application in its entirety within Visual Studio. Instead, you can use TFS Team Build or MSBuild directly.

The Partitioned Solution approach doesn't scale well for very large solutions since it will make the IDE very slow and this sends you down the Multiple Solutions approach. So you group related projects and create a solution for each group. You use project references for dependencies inside the solution and file references for those dependencies that cross the solution boundaries. This is where the problems start:

1- You cannot create a master solution that contains all of the projects. This is because you have created file references for cross-solution dependencies, which will cause problems when you try to build the master solution.

2- Depending on which area of the system you are working on, you may want to have a different slice of the system in your solution. For example, if you are a member of a team working on a specific feature such as Order Processing, you want to have a vertical slice that goes across application layers (presentation, business and data). But if you are working on the UI Framework for the application, you want to have a horizontal slice that includes the presentation layer from all functional areas as well as the UI Framework.

So even if all of the team members agree on the concept of Multiple Solutions, there are decision to be made on how the projects are going to be grouped into multiple solutions and as you can see in the above diagram, these categorisations don't necessarily play well with each other.

You always need to consider various factors such as the solution size and simplicity of the build process and choose one of these approaches (none of which are perfect):

Single Solution
Partitioned Solution
Multiple Solutions

Multiple Partitioned Solutions
Some of you may know about this already but there is another approach too. One can argue that it is the same as Partitioned Solution but in order to avoid confusion(!), I usually call it "Multiple Partitioned Solutions" or "MPS" (as you know we love TLAs). So what is it and how does it work?

MSBuild is a great build engine. One of its features is the ability to follow and find the project references in a project even if those referenced projects are not inside the solution you are trying to build. This means you no longer need to have all of the project references inside the solution. Believe it or not, but you can successfully build the solution and the projects inside it even if the referenced projects are not in the solution. This will work both from the IDE and the command line as they both rely on the underlying MSBuild functionality. The only condition here is that the referenced projects need to have been built already. MSBuild is able to follow and find those referenced projects but it won't build them for you. Is this a major problem? Probably not because when you get the latest version from the source control, you usually do a full build and then start working on your specific area.

Let's see how the system will be structured then. The dependencies between the projects are created as project references wherever possible. Depending on your requirements, you can create a solution that contains only a subset of projects you need to work on. Because the dependencies are project references, you can now have cross-cutting solutions that go across functional areas and architectural layers. You can also have a master solution because the dependencies are project references. Clearly, you don't want to open the master solution in the IDE often as it will take a long time to load, it will be slow and you don't usually work on all projects at the same time. The master solution will primarily be used for build purposes.

Note 1: I haven't tried this but as far as I know, you won't be able to build a solution on the build server if a project reference is missing. So on your build server, make sure you always build the master solution and not the partitioned solutions. You always want to build everything on the build server anyway.

Note 2: I am not saying that you should never use file references. There are cases where you don't want the dependencies to be built in the same build step so you can use file references if needed. The advantage of the Multiple Partitioned Solutions is that it gives you maximum flexibility.

Why do I call it "Multiple Partitioned Solutions"? Because the master solution is partitioned multiple times based on various perspectives. For example, the master solution can be partitioned into three solutions, one for each logical layer (such as presentation, business and data). At the same time, it can also be partitioned into another three solutions, one for each functional area (such as Order Processing, User Management and Call Centre).

Like the other approaches, The MPS approach is not perfect and it has its own challenges. I personally prefer this approach though. It addresses the concerns around solution size and versioning and is very flexible as you can have cross-cutting solutions. But from a tooling perspective, we can provide you with better support so this is an area for improvement. As an example, if you try to remove a project from a solution in Visual Studio, it removes all of the dependencies on that project too. If you are following the MPS approach, this is not necessarily what we want. This is not as bad as it looks as in most projects I have seen, the solutions are created and maintained by dev leads, architects and/or build engineers so as long as they know what they are doing, it will be fine but it would be nice to have a proper solution here.

I have found a workaround for this, which is to unload the projects that depend on the project we are trying to remove before removing the project. This will prevent the dependencies from being dropped automatically. Another approach is to manually edit the solution file and remove the project(s).

As I said, these are workarounds not solutions. When we remove a project, we ideally want to be able to specify whether we want the project to be removed from the dependencies or we are just trying to exclude that project from the solution. So maybe we could add an "Exclude" option to the project context menu in the Solution Explorer?

So... have you used the MPS approach in your development projects? If yes, can you share your experiences? What are the challenges you have faced and how have you addressed them? What kind of support do you expect from the IDE in this area?

Windows 7 Beta is Here

2009-01-08T08:31:00Z

Windows 7 Beta is now available for download from the MSDN Subscriber area. It will then become widely available for download on Friday (9 Jan) via http://microsoft.com/windows7.

I am very tempted to go ahead and install it as the base OS on my work laptop today but as usual, Microsoft IT have created the customised image to be used internally so I will wait until next week when I have physical access to the corporate network. My home desktop is very excited as its OS is getting an upgrade this evening :)