第 132 页

You have several ways to generate dump files, including the Windows Task Manager, WinDbg, and

Visual Studio itself. On Windows Vista or later operating systems, the simplest method is to

right-click the process in the Windows Task Manager and select Create Dump File.

One of the more functional tools for generating dumps is the adplus.vbs script, which is a

command-line interface to WinDbg. The adplus script and WinDbg are installed with the

Debugging Tools for Windows, which is available from http://www.microsoft.com/whdc/

DevTools/Debugging/. You must install the version that matches the processor architecture on the

target machine (x86, x64, Itanium).

To generate the dump file, open a command prompt, change directory to the install location of the

Debugging Tools, and enter the following command:

adplus -hang -pn processname.exe

This command attaches to the application called processname.exe in non-invasive mode, generates

the dump, and then detaches. The application will continue to run after this.

If you are debugging a hung application, an application that is using an excessive amount of

memory, or an application that is exhibiting unexpected behavior, you should take one or more

Post-Mortem Debugging .

901

memory dumps at the appropriate times. It may involve a degree of trial and error to ensure that you

generate a dump that contains useful information.

If you are debugging a specific exception that is being thrown in an application, you will need to use the

-c switch to pass in a file that configures adplus to generate a dump file when that exception is thrown.

You can also use Visual Studio 2010 to generate a dump file during a debug session. To do so, pause

execution and select Debug . Save Dump As.

debugging dump files

To get the most out of post-mortem debugging

you will need to configure Visual Studio to

load your symbol files. Symbol files have a

PDB extension and are generated as part of a

debug build. You will find them in the debug

output build directory; there is one for each

assembly that was built.

Under Visual Studio select Tools . Options

and then select the Symbols category under

Debugging. You can specify either a URL or a

local directory as the location of your symbol

files. The public Microsoft Symbol Servers

will already be included; add your own local

symbol directories, as shown in Figure 43-16.

Now that you have generated your dump file and set up the symbols, you use Visual Studio to begin

post-mortem debugging. Select File . Open . File and locate the dump file. Once opened, Visual

Studio displays the dump summary page as shown in Figure 43-17.

fiGure 43-16

fiGure 43-17

902 .

chaPter 43 AdVAnced debugging TechniQueS

Click the Debug with Mixed link to load the dump and all symbols and begin debugging. This link

is only displayed if the dump is from a managed application that targets the .NET Framework 4.0;

otherwise you can only use the Debug with Native Only option.

Debugging a dump file is much the same as any other debugging session — you can display the

call stack, inspect the contents of variables, and view the threads. The one main limitation is that

because you are looking at a snapshot, and not a live application, you cannot step through the

source code.

suMMary

This chapter completes the discussion on debugging your projects and applications, offering details

about advanced debugging techniques. Visual Studio 2010 is capable of meeting a wide spectrum of

debugging scenarios, such as multi-threaded applications, stored procedures, unmanaged code, and

even the .NET Framework itself. These techniques provide you with a set of very effective debugging

options for tracking down the issues in your projects regardless of language or technology.

PART X

build and deployment

.

.

: chaPter44

: chaPter45

Upgrading with Visual Studio 2010

Build Customization

. chaPter 46: Assembly Versioning and Signing

.

: chaPter47

Obfuscation. Application Monitoring, and Management

. chaPter 48: Packaging and Deployment

.

: chaPter49

Web Application Deployment

44

Upgrading with Visual

studio 2010

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.

uPGradinG froM Visual studio 2008

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

fiGure 44-1

Application projects reference the WCF Service Application project.

906 .

chaPter 44 upgrAding WiTh ViSuAl STudio 2010

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.

fiGure 44-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 the screenshot is the list of

projects that will be upgraded as part of the process.

Upgrading from Visual studio 2008 .

907

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.

fiGure 44-3

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

908 .

chaPter 44 upgrAding WiTh 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>

…

VS2008Solution\ClassLibrary1\ClassLibrary1.csproj

becomes:

<Project

ToolsVersion="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>

…

Upgraded\ClassLibrary1\ClassLibrary1.csproj

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 fi les by

having two solution fi les, 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.

uPGradinG to net fraMework 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.

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.

Upgrading to . neT framework 4.0 . 909

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.

fiGure 44 - 4

910 .

chaPter 44 upgrAding WiTh ViSuAl STudio 2010

fiGure 44-5

suMMary

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.

45

Build Customization

what’s in this chaPter?

.

Customizing the build environment

.

Performing actions at the beginning and the end of the build

.

Creating custom MSBuild scripts

Although you can build most of your projects using the default compilation options set up

by Visual Studio 2010, occasionally you’ll need to modify some aspect of the build process