Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

2.0 Port Update 2: Mixed Progress

After spending most of the day yesterday writing specifications for version 1.2 of the Digipede Network, I spent the afternoon continuing to migrate our projects over to VS2005. This went a little slower than expected, as I fell into a trap regarding upgrading ASP.NET projects.

The Gotcha

ASP.NET 2.0 projects are organized somewhat differently from their predecessors. One major change is that the project file is gone. This makes sense considering there has been much effort to make the Web site synonymous with the project itself. This means that every web page in a folder is a part of the project. Upgrading the project is simple: locate and open the old project file (.csproj in our case). VS2005 takes care of the rest.

But what if you attempt to upgrade it directly from source control? This works as expected for non-ASP.NET projects: simply select the project folder from source control. The project and related files are checked out from source control, and the project file is upgraded. But what happens for ASP.NET?

If you open an old ASP.NET project directly from source control, VS2005 doesn’t even look at the old project file (presumably it determines it is a Web project by the existence of web.config). It assumes that the project is in the new format. You do get prompted to upgrade to ASP.NET 2.0, but you don’t end up in the Upgrade Wizard. As a result, you get an application that has not been reorganized for ASP.NET 2.0.

So, don’t make this mistake! Get your files first and then upgrade from her whole project file.

ASP.NET 2.0 Reorganization re:Source Control

Another related issue is actually a slight beef I have with the Upgrade Wizard (OK, with the decisions made regarding it).

After upgrading your ASP.NET 2.0 project, you will likely get a message that says your project has been disconnected from source control. This is due to the project being reorganized. For example, shared source code files will have been moved into the App_Code folder. The solution suggested by the Upgrade Wizard is to add your project back into source control. Yes, that is a solution.

But what about file history? I take great pains to retain file history in source control. I don’t need to go into the reasons why (as I think they are obvious). It is important enough that I have manually tweaked the source control projects to retain the file history.? This is a bit of a time sink, but again well worth it.

Why doesn’t the Upgrade Wizard offer to move these files in source control? VS2005 does support source control file move (even with a VSS 6 source control provider). It would have saved me some hassle if this was taking care of automatically.

Inconsistency with Source Control

I found an inconsistency in the way the upgrade process deals with deleted files. In at least one case, the user is prompted to automatically remove the deleted file from source control. In another case, it is left to the user to go through the upgrade report and determine which file should be removed from source control:

  • XSDs (and related files) representing DataSets are converted from the old format to the new VS2005 format. In this process, a new file gets added (the Designer.cs file) which replaces the old code-behind file. In this case, VS2005 asks the user if the deleted file should be removed from source control.
  • The upgrade removes.resx files that contain only header information. Unfortunately, VS2005 does not from the user to delete these files from source control.

Tags: , , ,

    Trackback

No comments yet

Sorry, the comment form is closed at this time.