WHAT'S IN THIS CHAPTER?
Taking advantage of the new IDE when working on older projects
Updating projects to use the latest runtime and libraries
Each time a new version of Visual Studio is released, there is always a delay before developers start to use it. This is primarily due to the need to upgrade existing applications to a new version of the .NET Framework at the same time. For example, the migration from Visual Studio 2003 to Visual Studio 2005 required upgrading applications to version 2.0 of the .NET Framework. Since the introduction of multi-targeting in Visual Studio 2008, you have been able to upgrade to the latest IDE independently of moving to the .NET Framework version. This is particularly important if you still need to target older versions of Windows for which there is no support for the newer .NET Framework versions.
In this chapter, you see how easy it is to migrate existing .NET applications into Visual Studio 2010. This is done it two parts: upgrading to Visual Studio 2010 and then upgrading the .NET Framework version the application makes use of to 4.0.
To begin with, let's start with a solution that contains a good mix of application types. Figure 44-1 shows a Visual Studio 2008 solution that contains Class Library, Unit Test, WCF Web Site, Web Application, Windows Application, Workflow Application, and WPF Application projects. The WCF Web Site, Web Application, Unit Test, and Workflow Application projects all reference the Class Library project and the Windows Application and WPF Application projects reference the WCF Service Application project.
Note
The tools required to develop Windows Mobile device applications are not included in the initial release of Visual Studio 2010. This means that you cannot upgrade existing device applications from Visual Studio 2008 to Visual Studio 2010.
Upgrading this solution is as simple as opening it in Visual Studio 2010. This automatically invokes the Visual Studio Conversion Wizard, as shown in Figure 44-2. The wizard is relatively straightforward, with the only option being whether or not a backup is made of the solution before upgrading. If your solution is in source control, you can ignore this because you will be able to revert to the checked-in version if something goes wrong with the upgrade process. If your solution is not in source control, it is highly recommended that you allow Visual Studio to make this backup for you so you will have a working version if something goes wrong.
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 the screenshot is the list of projects that will be upgraded as part of the process.
Note
If you have a Web Site project in your solution, you will be prompted to upgrade it to version 4.0 of the framework during this upgrade process. If you opt not to make the change now, you can still change the target framework version later.
Even if the Conversion Wizard reports no errors, 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 44-3 and typically lists 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 some conversion issues, because some known breakages between the framework versions exist. Despite being able to target multiple versions of the .NET Framework, Visual Studio 2010 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.
With the multi-targeting capabilities of Visual Studio 2010, upgrading a solution does not mean updating the version of the framework that you are developing for. So, the question is what has been changed and what effect this might have. 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 10.00 # Visual Studio 2008
becomes:
Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010
The changes to the project file include some additional elements and attributes. For example, the following:
<Project
ToolsVersion="3.5"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{8735A946-4A21-4921-A4F9-E9645ABCF9ED}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>ClassLibrary1</RootNamespace>
<AssemblyName>ClassLibrary1</AssemblyName>
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
</PropertyGroup>
...
becomes:
<ProjectToolsVersion="4.0"DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <ProductVersion>9.0.30729</ProductVersion> <SchemaVersion>2.0</SchemaVersion> <ProjectGuid>{8735A946-4A21-4921-A4F9-E9645ABCF9ED}</ProjectGuid> <OutputType>Library</OutputType> <AppDesignerFolder>Properties</AppDesignerFolder> <RootNamespace>ClassLibrary1</RootNamespace> <AssemblyName>ClassLibrary1</AssemblyName> <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> <FileAlignment>512</FileAlignment><FileUpgradeFlags></FileUpgradeFlags><OldToolsVersion>3.5</OldToolsVersion><UpgradeBackupLocation /></PropertyGroup> ...
Note
If you have developers working with a mix of Visual Studio 2008 and Visual Studio 2010, 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 2010, 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 in order to use MSBuild version 4.0.
Once you have migrated your application across to Visual Studio 2010 and tidied up your build environment, you should consider the upgrade path to .NET Framework 4.0. Unlike the upgrade to version 2.0 of the .NET Framework, where there were a number of breaking changes, the upgrade to version 4.0 should be relatively painless. Although you may still need to make some changes, for the most part your existing application should be easily upgradeable.
In most cases, upgrading your application is just a matter of changing the Target Framework project property. Figure 44-4 shows the project properties dialog for a C# Class Library project. On the Application tab there is a drop-down that lists the different target frameworks that are available for you to select.
Note
For VB projects, this drop-down list is in the Advanced Compile Options dialog box, which you can access from the Compile tab in the project properties designer.
As soon as you select a new framework version, the dialog in Figure 44-5 appears. If you select Yes, all pending changes to the project will be saved and the project will be closed, updated, and reopened with the new target framework version. It is recommended that you immediately attempt a rebuild to ensure that the application still compiles.
In this chapter, you have seen how you can upgrade existing .NET applications to Visual Studio 2010 and version 4.0 of the framework. Using the latest toolset and framework version clearly has some advantages in performance, functionality, and usability. However, don't overlook the limitations that using the latest .NET Framework might impose. If your target market still uses old operating systems, such as Windows 2000, you may want to stay on version 2.0 of the framework, because this is supported on these platforms. Visual Studio 2010 allows you to have the best of both worlds, only upgrading as and when you want to.