Don't sweat migrating legacy .NET projects to Visual Studio 2008

I'm always a bit apprehensive when moving to a new development tool or a new version of an existing tool because of the possibility of breaking existing code and projects. Little did I know that migrating to Visual Studio 2008 would be such a breeze.

Visual Studio 2008 automates the conversion process and allows you to continue working with older versions of the .NET Framework. I migrated to Visual Studio 2008, and I have not encountered any problems.

I'll try to ease your concerns about migrating to Visual Studio 2008 with this overview of what a migration entails. (Note: if you're working in a team environment, all developers will need to use it.)

Conversion

Visual Studio 2008 offers a complete replacement for its predecessors. It has a great new feature called multi-targeting, which allows you to develop solutions for multiple versions of the .NET Framework beginning with 2.0 and higher.

The IDE interface adapts to the targeted version. While it provides this flexibility, it uses its own project and solution format, which is incompatible with previous versions. Note that, once you convert a solution to Visual Studio 2008, you cannot open it in previous versions.

Solution files are text-based files with the familiar .sln file extension. Project files are XML-based (using the familiar file extensions according to the language used, with .csproj for C# and .vbproj for Visual Basic).

The following sample is a project file for an ASP.NET project.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{001c5000-65df-11db-9384-00065a956f00}">
<WebProjectProperties>
<StartPageUrl>sample.aspx</StartPageUrl>
<StartAction>SpecificPage</StartAction>
<AspNetDebugging>True</AspNetDebugging>
<NativeDebugging>False</NativeDebugging>
<SQLDebugging>False</SQLDebugging>
<PublishCopyOption>RunFiles</PublishCopyOption>
<PublishTargetLocation></PublishTargetLocation>
<PublishDeleteAllFiles>False</PublishDeleteAllFiles>
<PublishCopyAppData>True</PublishCopyAppData>
<ExternalProgram></ExternalProgram>
<StartExternalURL></StartExternalURL>
<StartCmdLineArguments></StartCmdLineArguments>
<StartWorkingDirectory></StartWorkingDirectory>
<EnableENC>False</EnableENC>
<AlwaysStartWebServerOnDebug>True</AlwaysStartWebServerOnDebug>
</WebProjectProperties>
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
</Project>

Using the conversion wizard

Visual Studio 2008's conversion wizard automates the process of converting a solution to the new IDE. The wizard appears when you open a solution in Visual Studio 2008 built with a previous version of Visual Studio. The image below shows the initial window of the conversion wizard.

Visual Studio 2008 conversion wizard opening window

Converted solutions or projects are no longer compatible with Visual Studio versions prior to Visual Studio 2008. However, the projects may still use a previous version of the .NET Framework.

The conversion wizard automatically appears when an older solution is opened in Visual Studio 2008. The first step in the conversion process is the creation of a backup. (This is an optional step.)

The backup keeps a copy of the solution in its pre-converted state, so it can be used if you need to work with the solution in its version of Visual Studio. There may be significant delays, as files are copied during the backup process.

Conversion proceeds once a backup is created (the conversion process may take a few minutes depending upon the size of the project). If any problems are encountered during the conversion process, a conversion log is presented: otherwise, the conversion process continues.

Upon successful conversion, the wizard prompts you to upgrade the targeted version of the .NET Framework for the project, as shown below. This allows you to move to the .NET Framework 3.5. Any configuration (web.config, app.config, etc.) is modified, as well if you upgrade the framework used.

A successful conversion ends with a prompt to upgrade the .NET version.

There are a variety of problems that may arise in the conversion process that could result in an unsuccessful conversion. One problem I've seen repeatedly is the need to run the process as administrator when converting ASP.NET applications that use IIS, as opposed to the built-in Web server.

Problems may also occur if an application includes controls or extenders from the ASP.NET AJAX Control Toolkit, and you are upgrading to the latest version of the .NET Framework. You must upgrade to a new version of the toolkit in order to run with the .NET Framework 3.5.

If your environment includes a source-control system (which it should), all necessary files will be automatically checked out by the conversion wizard. The conversion will fail if a file cannot be exclusively checked out.

Batch conversion

One feature I especially like in Visual Studio 2008 is the support for batch conversion via the /Upgrade command-line switch for the Visual Studio 2008 executable (devenv.exe). This allows you to upgrade multiple projects or solutions via a simple command, or you may create a batch file with multiple commands.

Converting code after the fact

The multi-targeting feature introduced in Visual Studio 2008 is wonderful; it allows you to build solutions that use any version of the .NET Framework beginning with 2.0. If you choose not to convert a project's code to version 3.5 when using the conversion wizard, you can convert it later.

The target framework version is an option that is accessible via the properties of a project, as shown below. At this time, the target framework version allows you to choose one of these options: .NET Framework 2.0, .NET Framework 3.0, and .NET Framework 3.5. A project must be closed and reopened after its target .NET version has been changed.

Working with the target framework version of a project

Discuss your migration experience

Are you currently using Visual Studio 2008? Have you migrated projects to the new environment? What, if any, problems have you encountered with the migration? If you are still waiting to migrate projects to Visual Studio 2008, what is the main thing holding you back? Share your experience with the Visual Studio Developer community.