We made a decision on a project I've been on for over?a year now to upgrade to ASP.NET 2.0. This is my first major upgrade project, and to be honest, it was fairly smooth.

Now that we're on .NET 2.0, we have?a few issues, but we'll get to that. First, the upgrade process. We upgraded two projects that shared a library. We ran a test ahead of time, and did it disconnected from source control, and ran into one immediate issue: the first project upgraded just fine, but as soon as we tried to open the second project, it bombed because one of the projects had already been upgraded.

Easy enough to fix. We actually have about five or six projects, and every one of them uses the same shared library. Temporarily, we took a compiled version of the?shared library, checked it in, and then on all but one solution, removed the project. We then modified each project that had a reference to it to reference the DLL rather than the project, and ensured everything built just fine. Then we checked it all in that way.

Now we were ready for the "real" conversion. We made one obvious mistake?when we did it. Well, it was obvious afterwards, and I'm guessing there's some best practice document out there that says so, and I think I remember hearing something about it at Tech Ed, but we didn't listen. We upgraded while connected to source control - and not just that, but while files where checked in. That caused some issues for us. The biggest being that the project files were all modifed on the machine we did the upgrade on, but were never checked out. Again, easy enough to fix. We just checked out the project files on the upgrade machine without overwriting the local file and then checked in.

Looking back, there's one other thing I would have done differently too. I would go through and delete any file from source control that was not part of our web project. In VS.NET 2003, with a project file, you could exclude files and have them laying around the file system still. But with VS 2005's model, every file is part of the project. By removing erroneous files ahead of time, it would have been smoother for us. We ended up with a few files that weren't upgraded and weren't intended to be part of the project. But because they were in Visual SourceSafe, they were now part of our project.

Which brings me to my biggest gripe so far with Visual Studio 2005: The website project in a team environment. I love that Visual Studio now handles renaming and deletng files, and syncs that back to your source control provider, but if I delete a file, it's still on the other developers' machines. So when they go to check in, they could inadvertently re-add that file.

I know, I know. You're supposed to check what you're checking in (and - gasp - comment on what that check-in is for), but not everyone does that. I've known quite a few developers who right-click on the solution and go to Check-In (recursive). They assume that everything that's being checked in is a result of an action they've taken (they added the file, they checked it out, etc.) and not because of an action they didn't take (they didn't delete the file that someone else removed from the project). While you should know exactly what you are checking in, it's not really a bad assumption.

I know the web application model should take care of this, but it's still beta. I'm not sure I'm ready to recommend it to clients until I've had a chance to play with it myself - a good case for using it over at Tourney Logic!

Have you upgraded a project yet? How did it go? Any major gotchas you ran into?

Technorati Tags: ASP.NET | Upgrade