Connecting Visual Studio 2008 to TFS 2010

.. a note to self

And amidst all new versions of Visual Studio and Team Foundation Server I find myself at a client where there is a mixed codebase. Some older stuff created in VS2008 and even VS2005 and now working in VS2010. Luckily, they have their code on TFS 2010. For each version of Visual Studio code there is a collection aptly named VS2005 et cetera.
But then I struck the small challenge of actually getting to older code. I could connect to the collections using VS2010 and get latest from there and then I could open it using the correct version, but I completely lost the ability do any real source control.
I could not simply connect the older Visual Studio versions to TFS2010.

Now what?

Luckily this is something the people at Microsoft have anticipated. There are Forward Compatiblity Updates for older versions of Visual Studio:

• Forward Compatibility Update for VS2005 (Visual Studio 2005 SP1 is a required prerequisite).
• Forward Compatibility Update for VS2008 (Mind you the Visual Studio 2008 SP1 is required).

Almost there

When connecting to TFS2010 from older Visual Studio versions wen need to give a little more data than just the server name. The complete path to the collection is needed. You will get a TF31002 error when you only provide the server name.
In the Add Team Foundation Server dialog you will need to enter the following format in the Team Foundation Server name textbox:

•  http://{tfsserver}:{port}/{virtualdir}/{projectCollection}

In my situation I came to the following result.

And another trick learned

I hope this helps someone else as well. At least it is a note to self.

Zombies?

.. I ain't not afraid of no ghosts

While happily coding about the other day I hit Shift-F5 in Visual Studio and was greeted by the following dialog box:

Uh?

Get the gun and blow their brains out!

Well, I didn't. Just clicking the button made it go away. But I am on full alert now. But maybe I should visit this guy ...

Image by Getty Images via Daylife

Trouble with Team System workspace in VS2005

.. but I solved it

I have been developing in Visual Studio 2008 lately and the chances are reasonable that I will move to Visual Studio 2010 soon. However, in my current project I needed to create a SSIS thingy to do some clever data import. Since the database we are using is SQL Server 2005 I had to do a step down to Visual Studio 2005. Not a big problem since it's still installed on my machine.

Team System

Small problem was that we are using Team System for souce code control and work item management. That's a no brainer. Just download and install the Team Explorer for Visual Studio 2005.

Well easily done and away we go.

Login into the server and away we go!

Just a quick plug here. I am using an online hosted version of Team Foundation Server. It's provided by Online-TFS and works like a breeze. In a recent outsourcing job I had to work with a TFS instance hosted on the same internal network and that wasn't anywhere close in performance as this online version!

It may seem pricy at first, but I can access it from anywhere on the Internet and still have great performance.

After starting VS2005 I just had to logon and away I went. I quickly had the Team Explorer on screen and then I just wanted to hook up to the correct Workspace to start uploading the first version of SSIS project.

That's when things went a bit wrong. I had no options in the Source Control Explorer window. I could browse to the folders on TFS but couldn't add or get anything.

I was a bit stumped.

So I did search and found some stuff on MSDN about the File - Source Control menu. But that only showed Visual SourceSafe. Ugh!

I looked a little further and decided to go through the Options dialog where a lot of the hidden gems can be found.

The solution

Going through the good old Tools - Options menu I brought up the Options dialog. And there it was hiding under the Source Control item.

I just had to pick the right plugin from the box to get going.

While there I had a quick look at the other options to see if they suited me way of life and then clicked OK.

That's it

So then I could get cracking with the mysterious ForEach Loop Container.

Building an application (4) ...

.. weird debugging problem

One more thing that I have encountered on my wonderful journey in building my first Silverlight application is a debugging issue.

It just not works straight out of the box in Visual Studio 2008. I know, I know, it must be me with all sorts of software loaded or what. Or the missing hotfix 98662654a. But just keeps biting me.

What's up, doc?

I start VS 2008 and make some very very clever changes or just want to try out something. So I set a breakpoint at the right line in the code and hit F5. Easy.

Lots of things happen. The application is built. Well, three applications are built: the Silverlight app, the web app and the web service. So far, so good.

I start my testing and the breakpoints are never hit. At least the IDE does not stop.

And yes, I am running in Debug mode.

What's the cure, doc?

I have found that stopping the debug session (by hitting Shift-F5 in the IDE) and the right-clicking the Web Service project and selecting Debug - Start New Instance does the trick.

Breakpoints are once more hit and they do cause the code to break at those points.

So, what's up, doc?

I honestly can see here that I have no idea. The trick above works for me and to me that is enough.

So, if you come across breakpoints never really breaking than the above trick might work for you.

Building an application (2) ...

.. coming full circle

In the first part of this journey I have sketched the outlines of my application. The combination of web pages, web service and Silverlight as I plan to build it.

Jumping hurdles and dodging bullets

While building and debugging I have run into numerous obstacles. Not only did Chrome give me an unexpected headache by not refreshing the Silverlight XAP file in the cache, also Visual Studio behaved weirdly during debugging sessions. At first I couldn't make any of the breakpoints work. Only after using the context menu on the web service and picking 'Debug - Start a new instance' did execution break at the breakpoints. And then after a couple of hours it failed all breakpoints completely. Restart of Visual Studio and browser did not work. A full reboot did the job.

BTW I have logged a bug with Chromium for the caching problem.

However

My Proof of Concept piece of spaghetti has now come full circle:

1. I drag and drop some players, balls on the pitch.
2. Enter some extra info: name of the excercise and some extra text.
3. Save the data to the data base using the web service.
4. The asynchronous callback adds some html to the DOM, which is an image that is generated by a special HttpHandler.
5. The image shows up in the browser.
6. I have a smile on my face.

Lots of work to do

Image via Wikipedia

There is still lots of work to do:

• a real user interface has to be designed
• better, I need to sit down and get the complete UX designed
• have to add the boring user authentication stuff
• try out the concept on a real web server
• implement some of the missing graphical pieces, like lines with arrows
• think of good way of editing the lines
• undo / redo ?
• make the database complete
• add functionality for picking existing excercises, sharing these, copying, editing etc.

Yep, there is lots to do and so little time.

A little bit more tchnical info in Part 3.

Converting a WebSite project to a Web Application project

.. an interesting journey

In the last few weeks we have been preparing a conversion from a WebSite project to a Web Application project in Visual Studio 2005 solution. To complicate things a bit there is also SharePoint in the equation.

The reason to do the conversion was that we could not automate the build process in TFS and subsequently could not automate the deployment. Also the building of the solution itself within Visual Studio was handwork and took about forever.

What did we do?

Well, quite a lot was done to do the conversion. Along the process we were wishing louder and louder that someone had used his brain before picking the WebSite project. We had about 180 User Controls and about the same number of WebParts, that used these user controls. I know, what you want to say, probably not the best architectual design decision. But then again, when you do not take the time to think about the architectual design no one can put the blame on you for making the wrong architectual design . Duh.

We needed to do a two fold conversion: once for the User Controls and once for the WebParts.

Image by Getty Images via Daylife

Converting the User Controls

We created a new Web Application project, deleted the Default.aspx and the Web.Config files and then copied all user controls from the WebSite project. Then we did a Convert to Web Application action through the context menu in the Source Explorer. This adds a.o. the designer files.

Using a specially written tool we processed all ascx and ascx.cs files to add namespaces, change and delete some of the attributes on the <%@ Control %> node. And we added a <%@ Assembly %> node.

Converting the WebParts

In the WebParts the UserControls were instatiated in the CreateChildPanel() method by calling the constructor. That needed to be replaced by a Page.LoadControl() command. Another tool was created to do that conversion.

Bumps in the road

We first figured the process out by creating a small and simple Proof Of Concept. That worked like a breeze. Then we started on a copy of the real code. Yep, that's when the manure hit the propellor. We came across multiple problems, mostly because of inconsistencies in the coding. Sometimes there were comments when did not expect them or a code file was not placed in the correct folder. So, some of our assumptions failed and we had some manual clean up after our conversion tools. But that was limited to roughly 20 files. Not too bad.

But we also saw that our Proof Of Concept was many times less complicated than our real world code. That kept us busy with debugging for quite a few days. That and the fact that we were not experienced SharePoint deployers did nt help speed things up.

Ready to roll

Last friday we were ready to roll. We had figured everything out and had fixes for all the small problems that we encountered. So, the monday was set as the big conversion day. We mailed our offshore team in India to stop any work on the code around noon and made a branch in TFS.

The Big Bang conversion

With the script in hand we took the steps one at the time and started the conversion at half past one. Ticking off each step we were ready to try and compile about an hour later. More manure hitting the fan. Some caused by missing references and some by the new code that was created by our friends in India. They did coding while we were testing out the conversion so we were now working with a new code base. So afcing some new interesting bumps.

We only had to do some things a second time, having forgotten to update one of our conversion tools. Gradually we saw the number of build errors go down from 300 and then up a bit again. And finally at half past seven we had a fully building situation we then checked in in TFS.

Today

Today, we hear some enthousiastic noise from fellow developers who find that the solution compiles a lot easier, without any manual building of separate projects and above all a lot faster than before.

Also we are now starting testing the deployment and ironing out any last bugs that are in there.

Lessons learned

The most important lessons learned is that especially in bigger application development projects it is absolutely necessary to think before you do, design before you start building as that will save you loads of time and trouble later on.

Further we have learned a lot about conversion and file manipulation through RegEx and changing files loaded into MemoryStreams which was an interesting excercise as well.