46.1. Upgrading from Visual Studio 2005

To begin with, let's start with a solution that contains a good mix of application types. Figure 46-1 shows a Visual Studio 2005 solution that contains Web Site, Class Library, Device Application, Web Service Application, and Windows Forms Application projects. The Web Site and Web Service applications both reference the Class Library, and the Windows Forms Application references the Web Service Application.

Figure 46.1. Figure 46-1

Upgrading this solution is as simple as opening it in Visual Studio 2008. This will automatically invoke the Visual Studio Conversion Wizard as shown in Figure 46-2. The wizard is relatively straightforward, with the only option being whether or not a backup is made of the solution before upgrading. This is highly recommended if your solution is not in a source control repository so that you have a backup. However, if you use a source control you can ignore this, because you can simply revert to the checked-in version if something goes wrong during the upgrade process.

Figure 46.2. Figure 46-2

The Summary screen indicates that your solution will be checked out of source control so that changes can be made. It also indicates that in some cases there may be some framework and reference changes made as part of the upgrade. What you can't see in this screenshot is the list of projects that will be upgraded as part of the process.

Even if there are no errors raised during the upgrade process, it is still recommended that you look through the conversion log after the wizard closes. This log (UpgradeLog.XML, found in the solution folder) looks similar to Figure 46-3 and will typically list the solution and project files as the only things that have been upgraded. If you are upgrading a pre-Visual Studio 2005 solution, you may find that there are some conversion issues, because there are some known breakages between the framework versions. Despite being able to target multiple versions of the .NET Framework, Visual Studio 2008 is limited to version 2.0 and above. So, if you have a solution that uses a version prior to this, the conversion wizard will attempt to upgrade it.

Figure 46.3. Figure 46-3

Upgrading this solution to Visual Studio 2008 will not change the version of the .NET Framework that the application targets. So, the question is what has been changed and what are the implications. The answer is that there are minimal changes to both the solution and project files. In the solution file the changes may be as subtle as the header. For example, the following:

Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005

becomes:

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008

The changes to the project file include some additional elements and attributes. For example, the following:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
        <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
        <ProductVersion>8.0.50727</ProductVersion>
        <SchemaVersion>2.0</SchemaVersion>
        <ProjectGuid>{E9D90EE1-60A0-4740-8E3E-8F9E98202D50}</ProjectGuid>
        <OutputType>WinExe</OutputType>
        <StartupObject>SampleWindowsApplication.My.MyApplication</StartupObject>
        <RootNamespace>SampleWindowsApplication</RootNamespace>
        <AssemblyName>SampleWindowsApplication</AssemblyName>
        <MyType>WindowsForms</MyType>
    </PropertyGroup>
    ...

becomes:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
         ToolsVersion="3.5">
    <PropertyGroup>
        <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
        <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
        <ProductVersion>9.0.21022</ProductVersion>
        <SchemaVersion>2.0</SchemaVersion>
        <ProjectGuid>{E9D90EE1-60A0-4740-8E3E-8F9E98202D50}</ProjectGuid>
        <OutputType>WinExe</OutputType>
        <StartupObject>SampleWindowsApplication.My.MyApplication</StartupObject>
        <RootNamespace>SampleWindowsApplication</RootNamespace>
        <AssemblyName>SampleWindowsApplication</AssemblyName>
        <MyType>WindowsForms</MyType>
        <OldToolsVersion>2.0</OldToolsVersion>
        <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
        <PublishUrl>publish</PublishUrl>
        <Install>true</Install>
        <InstallFrom>Disk</InstallFrom>
        <UpdateEnabled>false</UpdateEnabled>
        <UpdateMode>Foreground</UpdateMode>
        <UpdateInterval>7</UpdateInterval>
        <UpdateIntervalUnits>Days</UpdateIntervalUnits>
        <UpdatePeriodically>false</UpdatePeriodically>
        <UpdateRequired>false</UpdateRequired>
        <MapFileExtensions>true</MapFileExtensions>
        <ApplicationRevision>0</ApplicationRevision>
        <ApplicationVersion>1.0.0.%2a</ApplicationVersion>
        <IsWebBootstrapper>false</IsWebBootstrapper>
        <UseApplicationTrust>false</UseApplicationTrust>
        <BootstrapperEnabled>true</BootstrapperEnabled>
    </PropertyGroup>

If you have developers working with a mix of Visual Studio 2005 and Visual Studio 2008, you can have them all work off a common set of project files by having two solution files, one for each version of Visual Studio. Even after upgrading the project to Visual Studio 2008, they can still be opened in both versions of the IDE. Unfortunately, the same is not true of MSBuild — once you upgrade your projects you must also upgrade your build process to use MSBuild version 3.5.