In place code move – manually from TFS to TFS

Manually moving code between two TFS servers while leaving it in the same place can be a bit confusing. I was trying to guide somebody through the steps on Twitter recently and thought it might be better as a step by step reference guide, so here goes.

As a primer, if you’re not confident with workspaces and working folders, I recommend you take a look at Martin Woodward’s explanation of workspaces and his follow-up on working folders. These are both great articles and will give you a solid understanding of the way in which these concepts are used.

• Unbind from your existing server. This is done via File -> Source Control -> Change Source Control and unbind those you want to move

• Remove the path mapping from your workspace by either removing the workspace itself, or just the path you want to move if the workspace is larger than what you want to move.

• File -> Source Control -> Workspaces

• Remove the paths you don’t need mapped (or use the remove on the previous screen to remove the whole workspace)

• Change TFS servers to your target server via Team Explorer

• Hit the Connect to a Team Project toolbar item

• Either pick your new server from the drop down list, or map a new server.

• Pick the team projects you’d like to see. If you’re using TFS 2010 as either of your servers you’ll need to pick a team project collection.

• Map the path of the code you want to move into a workspace on the target server
  • File -> Source Control -> Workspaces
  • Either add a new workspace for the path, or add the path to an existing workspace
• Use the File -> Source Control -> Add to Source Control to drop the code into the target server

• Check In!

Hopefully this will allow you to move a solution about a little more seamlessly. If you require more than a basic code move (work items or history for example), you should potentially look at other solutions such as a TFS to TFS synchronisation tool.

Exploring the TFS API – Change Sets, Work Items and a Null Reference Exception

When using TFS it is good practice when checking in to associate with a work item to describe the cause for change. This creates a relationship between the change set created during the check in and the work item. It’s also exposed through in the TFS API as a property on the change set known as WorkItems. The great thing about this is that it lets you traverse the link in a natural manner, without having to set up the link queries yourself. This is not without its gotcha’s however, as I discovered…

To get your hands on the change set, you’ll initially need to set up a version control server object. Something to watch out for here is when scoping the lifetime of your server object that you’re going to use to get the change set you’ll need to take into account when the work item query is going to happen. You see the property is actually a bit clever about how and when it loads the work items that populate the list. When you obtain your change set, the version control service that you’re using is stored in a property of the change set.

Enter the dangers of not being scope aware!

The issue I am alluding to not so subtly to is one where you de-scope the original team foundation server instance, leaving the change set without an internal (open) server reference. This normally wouldn’t be an issue, as we’ve already got the change set – right? Some digging in reflector shows that our WorkItems collection is actually a lazy load collection, populated on first call and cached thereafter. The process is roughly as follows:

When you run your first get on the list, an instance of the WorkItemStore service is created and a query executed to get the referencing work items. The list of referencing work item URI’s is then used to fetch the work items, and populate an internal list (effectively caching the list for future reference). A clone of the internal list is then returned as the result.

What does this mean to you?

Well, if you scope your server instance with a using statement that is closed before you make use of the WorkItems property your server object (and the internal one used by the WorkItem property) will have already been closed and you’ll recieve a null reference exception. There are 2 ways around this, which you chose is dependent on your scenario. First, include your code that will query the work item list in the appropriate scope. This will extend the lifetime of your server object by the execution time of the extra code at least. The second option is to make an immediate call to the WorkItems property to populate and return you the list, and then allow the server object to be disposed as normal. This means the server object will be closed earlier, but you’ll be carrying around the work item list in memory for longer.

TFS and Excel – The Basics

Flicking through my blog stats on a Friday shows an interesting trend. On Friday my most common search term is generally “connecting to TFS in Excel”. This tells me 2 things – lots of reports are being written on a Friday, and there’s some demand for a starter guide for TFS and Excel integration!

First things first – licensing. The licensing requirements to connect to TFS from Excel and generate reports is fairly simple. You need a CAL. The people you distribute your reports to as either an xls(x) or hard copy won’t require a CAL, with the restriction that they can’t access the server to refresh/update/create data. For more info on licensing you can get the appropriate white papers for 2005 from here, and for 2008 from here.

Right, now we’ve made sure we’re covered by the right license we need a way to connect to TFS.

1. Install Team Explorer

If you’re using 2005, and have the TFS install media you can find it in the TFC directory of the media. Don’t have access to the install media? It’s also available for download from here.

If you’re looking for the 2008 version, you can get it from here.

The downloads both come in the form of an ISO, so you’ll need some kind of ISO reader. WinRAR and 7-zip will both let you extract what you need to do the install. Once you’ve got the files out, it’s a matter of following the bouncing ball through the setup wizard.

2. Open Excel

Now we’ve got a way to connect to TFS, the next step is to open your flavour of Excel. If you’re working with 2003 you should see a toolbar similar to the image below:

Excel 2003 Team Toolbar

If you’re using 2007, you’ll get a ribbon that looks like this:

Excel 2007 Team Ribbon

If you don’t see one of the above, check your install to make sure it completed successfully. You should see an item in your add/remove programs that looks a bit like this

Team Explorer

–Update–

If you’re running Office 2007 you can also check the status of the add-in in Excel. Instructions on the WIT Tools blog here.

3. Get a list of work items

To get the list of work items you’d like to work with you’ll need to click the ‘New List’ button in the toolbar installed with Team Explorer. Depending on your configuration, you might get a credential prompt at this point. If you do, enter the credentials that you usually use to connect to TFS (if you’re unsure, best to contact your TFS admin to find out which set you should be using).

You should then see a dialog asking you to pick a server, and team project to connect to. You’ll need to specify a server if you haven’t already. You can do this by clicking the servers button, then the Add… button.

Connect to TFS Server

Finally enter the URI and the configuration used to connect to your TFS instance. Once again, if you’re unsure – best to contact your TFS admin for these values.

Once you’ve set up a server, pick the team project you’re interested in reporting on and click OK. Double clicking the team project also works.

You’ll now be prompted to pick a query that will form the basis of your work item list. If you like, you can also pick the ‘Input List’ option to enter work items. The queries listed are those specified against the team project you selected. This means if none of those presented suit your needs and you’re not that keen on re-filtering every time you open excel you can go define a new work item query that you can use later to generate lists.

Once you’ve picked a query and clicked OK, Excel will head off to TFS and start building your list. From here on in you’re in Excel land and can generate pivot tables, charts and filtered lists all based off the data you’ve extracted. You can also add work items by entering data into the blank row at the bottom of your list that is denoted with an asterisk.

If you are adding new data – or updating items via the Excel list, you’ll need to hit the publish button to push this data back to TFS before it’s in the system though. An important thing to note here is that if you refresh your data set before publishing any changes you’ve made will be lost. This also applies to any custom formatting you’ve applied to the work item list (though this scenario is addressed in the 2010 integration model).

Well that’s about that. A basic guide to getting a work item list from TFS in Excel that will hopefully simplify the reporting story that most of us go through at some point.

TFS to Quality Centre Connector – The Official Word

If you go looking for info on the quality center connector you’ll most likely find Jim Lambs blog entry which points back to the connect site for the connector. The problem here is that the connector documentation clearly specifies that this release is of pre-release quality and should not be considered for production systems.

While this isn’t an issue in itself – there’s not much more info out there on the path forward for the connector. I sent an email through to Jim via his blog to see if I could get an idea on what the plan was for the connector. He got back to me within a day to indicate that the connector was effectively not resourced and most likely won’t achieve a production release quality.

With 2010 on the horizon, this isn’t all that surprising as the team is quite busy. The good news is that Jim also indicated that the team are working on a connector for the next version of the product to ensure a path forward for those intending to use Quality Centre with TFS!

VSTS presence on MSDN grows

I’ve been looking around at integration tools for TFS this afternoon and have just come across a new MSDN page on the VSTS subsite. There’s now a TFS migration and integration tools site, cataloging both free and paid solutions to various client stories for different tool sets.It’s already put me onto a couple of tools I hadn’t seen yet!

Thanks for the awesome resource guys!

TFS and Excel – Did you know?

One of my favorite integration points for TFS is Office. Seriously! I find excel the most intuitive and natural way to work with my iteration plans, bug lists and perform general task management. Having talked to a few people about this recently it seems that a lot of the TFS and Office integration is going unused, so I decided to start a living post to catalog some of the Q & A I come across to hopefully increase the use of some of my favorite features….

1. Excel as a task entry system

Excel works really well as a list management tool. What people don’t realise is that it can also be used to create lists for publishing to TFS, and it’s really quite simple.

a. Connect to your team project in Excel and get a list of work items from a query (n.b. you can also pick the ‘Input List’ option here which will open an empty list for entry).
b. Note the empty line at the end of the list marked with a *
c. Start entering your data into the empty line, and be sure to fill out all mandatory fields (you’ll get a prompt later if you don’t, so it’s not a show stopper)
d. Once you’re done entering your new tasks, hit publish to push these back to TFS.
e. If you get a prompt regarding required fields, update your data and try publishing again.

That’s it! You’ve just added a list of work items to your Team Project!

2. Excel, TFS and Concurrency

I was doing a pre-presentation review last week, and a discussion started about the Excel and TFS concurrency model. During the discussion I was asked if 2010 addresses the issue of ‘last-in-wins’ concurrency that exists in 2008. This seemed a little strange to me as I wasn’t aware of the issue but I answered that it did – as I had seen the resolution dialogue in 2010.

Having answered the immediate question, I decided that I’d find out exactly what the case was in 2008 as looking at the work item tracking tables I didn’t see a reason that work item version changes couldn’t be identified between fetch and publish in Excel. It turns out that the concurrency model for 2008 behaves the same (on the surface at least) as that in 2010.

The behavior is that when you publish back to TFS a conflict check occurs. If a non-blocking conflict – users have edited different fields in the same work item, is detected an auto-resolution will occur and the publish will complete. If a blocking conflict – users have edited the same fields in a work item, is detected then a conflict resolution dialog will be shown. This dialog allows you to select the change you want to keep, and then to continue with the publish operation.

Conclusion

So, there’s a couple of features around Excel and TFS integration that I’ve been asked about recently. If you have any other questions on any version of the integration (including any for any of the other Office integration points) leave them in the comments and I’ll do my best to get an answer!

PDC and Visual Studio 2010 – Just wow.

PDC is over for another year, and despite not being there, thanks to the excellent video coverage I’ve managed to almost drink my fill of the waterfall of content that’s poured out. One of the highlights for me was all the new VSTS bits and pieces that have been demo’d as part of PDC and the new CTP that was released (here). There’s a ton of great stuff coming down the line from the VSTS guys and with a really serious focus on software quality things are going to get a whole lot better in the dev/test world.

My top 3 highlights from PDC are:

1. The no more ‘no repro’ features of the test tools. These include the historical debugging – which is amazing in it’s own right, the manual test video capture and the integration between these and the work items.

In my mind this is going to greatly enhance the relationship between developers and testers. It’s something I’ve seen bits of before, in suites like those provided by Mercury and the video alone is priceless. I mean, how many times have you got a bug as a dev (I know, you don’t write bugs ) and thought… How in the heck did they do that??

2. The branch/merge visualisations and branches as first class citizens. When giving an RDN last week in Melbourne the number one post-talk question was around branching and merging strategies. This is an area of pain for many a first time build manager, and can cause hours of frustration and confusion if not done well. There’s plenty of good guidance out there (see my last blog) but in my mind nothing beats a good visualisation. If I can see where my code has gone, both upstream and down I’m going to be able to isolate the integration bugs a lot faster and more reliably. No longer will I need to go see the branch owner (whoever that is) and say… “Did you merge from last nights changes?”.

3. TFS administration/install and scaling improvements. The big highlight here is the ability to do things like re-run the setup tool, built in best practices analysis on setup and the separation of the 1:1 application tier and data tier relationship. There’s a serious step towards efficient and effective hosted TFS instances here with the movement of the unit of isolation to the team project level, allowing each project on a TFS instance to be managed alone and visible only to people directly involved.

There’s plenty more stuff in the PDC video collection that I’m yet to get through. There’s lots of talk on our internal mailing list about the ‘cloud’ products and how we can make use of them to drive the future of applications. I’m yet to watch this content but there are a couple of ideas I’m kicking around. I’d like to get other people’s opinions on Microsoft’s cloud offerings. What do you think? Can you see an opportunity for innovation? Last but not least – what are your PDC highlights?

Creating Sharepoint WSP’s with MSBuild

Over the last couple of work days I’ve been conjuring up a build task to package up the files required to deploy a sharepoint feature. Most of my work was driven via Doug Perkes blog post. The post covers a lot of the little things that are required when using the makeCab utility to generate a WSP file for deployment however I slightly altered the reg ex replacement he does to add the required assemblies into the definition file. My changes to his process are: Where he tells you to replace all the hard coded paths to your assemblies with a reg ex recognisable string I remove all hard coded paths and only provide a single place marker. e.g.

#FeatureAssemblyFiles#

Then I define an item group outside of the sharepoint feature build target with the following: <ItemGroup> <Assemblies Include="$(OutDir)\*.dll" /> </ItemGroup> Once the item group is defined I define a property that concatenates the assemblies into a correctly formatted string for use in the definition file using CreateProperty as so

<CreateProperty Value="@(Assemblies->'%22$(OutDir)%(FileName).dll%22 %22%(FileName).dll%22', '%0D%0A')"> <Output TaskParameter="Value" PropertyName="OutputAssemblies"/> </CreateProperty>

Once I’ve defined all that data, I simply use the FileUpdate task as per Doug’s instruction with the minor variation of using the $(OutputAssemblies) property as my replacement text instead of his string formatting (which was used in the create property in this case).

<FileUpdate Files="WSPBuild\WorkingSolution.DDF" Regex="#AssemblyFilePath#" ReplacementText="$(OutputAssemblies)" />

I also added a delete files task onto the end to clean up the working definition file. This can be commented out during debug so that you can inspect the file if required, but it’s a nice to have on the build server.

Resuming conflict resolution with TFS and Visual Studio

Have you ever cancelled out of a conflict merge dialogue only to realise shortly after that you couldn’t get it back and you needed to finish up the merge? I have. Fear not though – there is a way to get the it to reappear!

Head up to your File menu, browse to Source Control and click the ‘Resume Conflict Resolution…’ menu item. Visual Studio will re-query your conflicts and allow you to continue to resolve these issues.