Migrating to a "Web Application Project" in 2.0 when you have your 1.1 Application in TFS

  • Article

Normally within PSS, we have Breadth Queue's and Depth Queue's. I for example work in a Depth Q, what that means is that I only deal with issues related to ASP.NET and IIS and nothing more than that. So if you were running into a problem related to client side JavaScript you would go to the Internet Explorer Team and if you run into an issue related to say invoking a Web Service, you should be talking to the Distributed Services team.

The reason I am trying to explain how we work is related to a problem I ran into recently which had me stumped (bowled out)  for a while. This was one of those problems that falls into that unknown zone, sort of like the "No Man's Land". It was a problem with TFS and migration in ASP.NET.

 

So here is a brief about the problem. Customer had a huge Web Project and supporting Class Library projects all under one Solution File. They had everything working fine in Visual Studio.NET 2003 and they were using a 3rd party source control. Once TFS came into the picture, they had learnt that they could also use TFS as a source control and migrated everything to the Team Foundation Server. Everything worked fine and no issues so far.

But then the requirement came in to migrate the project to Visual Studio 2005 and ASP.NET 2.0. On evaluation they decided to migrate to a Web Application Project as opposed to a Website model. At this point I guess they might have thought that since we already have it in TFS we wouldn't need to unbind the project or something from source control and just opened the Solution File (in VS 2005) to start of the migration process to WAP. Lets assume that the migration went on smoothly and the project built successfully, since that's not the problem area I am talking about.

Right after the migration they checked in the solution file. But when the next time a developer would get the files and double click the solution file (from within TFS) to open the project, the following message would pop-up.

---------------------------
Source Control
---------------------------

The following Web projects must be converted to the new Web Site format. The conversion process will remove all source control bindings and the project will not be under source control after migration

C:\inetpub\wwwroot\MyTestProj\MyTestProj.vbproj

-----------------------------------------------
OK HELP
-----------------------------------------------

Followed by the message.

---------------------------
Microsoft Visual Studio
---------------------------

Some of the properties associated with the solution could not be read.

---------------------------
OK
---------------------------

 

Interestingly these message do not effect the projects itself. The projects stay migrated and when they were working with these projects there is no issue. After doing some Research on his end, the customer had found out that by removing the entries for SccEnlistmentChoice in the solution file, the messages would go away as long as the solution file stays checked out, but as soon as he check's in the solution file and opens it the next time, the problem came back.

When one of my team members got a call from the customer, after getting the problem description, we assumed that this is a problem related to TFS and nothing really to do with migration, after all, when we migrate a project that's not a part of TFS from VS.NET 2003 to VS 2005 WAP model, we don't get this message, right? And what about these weird entries, they appear to be source control related. We discussed this with the TFS folks and they agreed to work on part of the case.

Normally when issues like this arise where we have no clue about which team takes care of it, I don't worry too much about who should be driving the case, as long as due diligence is done and the customer goes back happy. So, I was perfectly happy to "bide my wee" and wait for the problem to get solved. But the problem kept dragging on. When I came into the picture we were at a stalemate and no specific direction.

The first thing I did was to request for a lab machine and try to setup a Repro of the problem. I called the customer and asked him to help me reproduce the problem. As all good Repro's this one didn't fail either and I wasn't able to reproduce the behavior. I went back and digged through the documentation, Source Code etc with no luck. It was only later that I realized how stupid I had been, In my Repro I was migrating to a regular WebSite project and not a "Web Application Project"

Once I corrected this error, I could immediately reproduce the behavior. Once a successful Repro was in place, I just had to play around with the SLN files, the Source control files and come up with the solution. The tool I used here was WinDiff, a file comparison tool. The solution was to delete the file VPSCC which gets generated for each project and manually edit the Solution File to remove the entries related to SccEnlistmentChoice. Once I got the solution it was easy to search for the answer. It appears that when we migrate a project which is already in the Source Control. The VPSCC file has an entry in it called "ENLISTMENT CHOICE" and this is set to "COMPULSORY". Since TFS will re-generate this file, its best that we get rid of this file and when we check-in the solution file, it will re-generate it with the correct entries.