饭饭TXT > 学习管理 > 《Visual Studio 2010 高级编程（英文出书版）》作者：Nick Randolph/等【完结】 > [Visual.Studio.2010.高级编程].Professional.Visual.Studio.2010.txt

第 134 页

作者：Nick Randolph/等当前章节：15406 字更新时间：2026-6-18 14:51

tool generates an assembly that contains an XmlSerializer for serializing (and

deserializing) a specific type. Normally these assemblies are generated at run time

the first time an XmlSerializer is used. Pre-generating them at compile time can

improve the performance of the first use. Serialization assemblies are named

TypeName.XmlSerializers.dll. See the documentation of Sgen.exe for

more info.

Target CPU: Depending on what CPU types are known to your system, this option enables

you to optimize the build output to a specific platform. The default option of AnyCPU

provides output that can be run on any CPU that supports the .NET Framework.

Target Framework: This is the only option in this dialog that applies to all configurations

and is used to determine what version of the base class libraries the project is compiled

against.

build events

You can perform additional actions before or after the

build process by adding them to an events list. Click the

Build Events button on the My Project Compile page to

display the Build Events dialog. Figure 45-6 shows a post-

build event that executes the project output after every

successful build.

Each action you want to perform should be on a separate

line, and can be added directly into either the Pre-build

Event Command Line text area or the Post-build Event

Command Line text area, or you can use the Edit Pre-

build and Edit Post-build buttons to access the known

predefined aliases that you can use in the actions. fiGure 45-6

918

chaPter 45 build cuSTomizATion

If your pre- or post-build event actions are batch files, you must prefix them with

a call statement. For example, if you want to call archive_previous_build.bat

before every build, you need to enter call archive_previous_build.bat into

the Pre-build Event Command Line text box. In addition to this, any paths that

contain spaces should be encased in double-quotes. This applies even if the path

with spaces comes from one of the built-in macros.

Shown in Figure 45-7, the Event Command Line dialog includes a list of macros you can use in the

creation of your actions. The current value is displayed for each macro so you know what text will

be included if you use it.

fiGure 45-7

In this sample, the developer has created a command line of $ (TargetDir) $ (TargetFileName) $

(TargetExt), assuming that it would execute the built application when finished. However,

analyzing the values of each of the macros, it’s easy to see that the extension will be included twice,

which can be amended quickly by either simply removing the $ (TargetExt) macro or replacing the

entire expression with the $ (TargetPath) macro.

At the bottom of the Build Events dialog there is an option to specify the conditions under which the

Post Build Event will be executed. The valid options are:

Always: This option runs the Post Build Event script even if the build fails. Remember that

there is no guarantee when this event fires that Visual Studio has produced any files at all,

so your post-build script should be able to handle this scenario.

On Successful Build: This is the default option. It causes the Post Build Event script to be

run whenever the build is considered to be successful. Note that this means that it will run

even if your project is up to date (and therefore is not rebuilt).

C# Build Pages .

919

When the Build Updates the Project Output: This option is very similar to On Successful

Build, except that it only fires the Post Build Event script when the project output files have

changed. This is a great option for keeping a local cache of archived builds of your projects

because it means you will only copy a file into the archive if it has changed since the last build.

There are no filter options for determining if the Pre-Build Event will be executed.

c# build PaGes

C# provides its own set of build options. In general, the options are the same as those available to a

Visual Basic project, but in a different location because C# programmers are more likely to tweak

the output than Visual Basic developers, who are typically more interested in rapid development

than in fine-tuning performance.

Instead of a single Compile page in the project property pages, C# has a Build page and a Build

Events page. The Build Events page acts in exactly the same way as the Build Events dialog in Visual

Basic, so refer to the previous discussion for information on that page.

As you can see in Figure 45-8, many of the options on the Build page have direct correlations to

settings found in the Compile page or in the Advanced Compiler Settings area of Visual Basic.

Some settings, such as Define DEBUG Constant and Define TRACE Constant, are identical to their

Visual Basic counterparts.

fiGure 45-8

However, some are renamed to fit in with a C-based vocabulary; for example, “Optimize code” is

equivalent to “Enable optimizations.” As with the Visual Basic compile settings, you can determine

how warnings are treated, and you can specify a warning level.

920

chaPter 45 build cuSTomizATion

Clicking the Advanced button on the Build page

invokes the Advanced Build Settings dialog, shown

in Figure 45-9, which includes settings that are not

accessible to Visual Basic developers. These settings

give you tight control over how the build will be

performed, including information on the internal

errors that occur during the compilation process and

what debug information is to be generated.

These settings are mostly self-explanatory, so the

following list is a quick summary of what effect each

one has on the build:

Language Version: Specifies which version

of the C# language to use. The default is

to use the current version. In Visual Studio 2010, the other options are ISO-1 and ISO-2,

which restricts the language features to those defined in the corresponding ISO standard.

Internal Compiler Error Reporting: If errors occur during the compilation (not compilation

errors, but errors with the compilation process itself), you can have information sent to

Microsoft so it can add it to its revision of the compiler code. The default setting is Prompt,

which asks you whether you want to send the information to Microsoft.

Other values include None, which won’t send the information; Send, to automatically send

the error information; and Queue, which adds the details to a queue to be sent later.

Check for Arithmetic Overflow/Underflow: Checks for overflow errors that can cause

unsafe execution. Underflow errors occur when the precision of the number is too fine for

the system.

Do Not Reference mscorlib.dll: By default, the mscorlib.dll, which defines the System

namespace, is automatically referenced in your project, but you can check this option to

build your own System namespace and associated objects.

Debug Info: Identical to the Visual Basic Generate debug info setting.

File Alignment: Used to set the section boundaries in the output file, and enables you to

control the internal layout of the compiled output. The values are measured in bytes.

DLL Base Address: Identical to the Visual Basic setting of the same name.

Using these settings for your projects enables you to closely control how the build process will

perform. However, you have another option with Visual Studio 2010, which is to edit the build

scripts directly. This is made possible because Visual Studio 2010 uses MSBuild for its compilations.

Msbuild

Visual Studio 2010 uses MSBuild, which is the compilation engine Microsoft originally released

with Visual Studio 2005. It uses XML-based configuration files to identify the layout of a build

project, including all of the settings discussed earlier in this chapter, as well as what files should be

included in the actual compilation.

fiGure 45-9

MsBuild .

921

In fact, since Visual Studio 2005, Visual Studio uses MSBuild configuration files as its project

definition files, in place of the old project file formats used by previous versions of Visual Studio.

This enables the MSBuild engine to be used automatically when compiling your applications within

the IDE because the same settings file is used for both your project definition in the IDE and the

build process.

how Visual studio uses Msbuild

As already mentioned, the contents of Visual Studio 2010 project files are based on the MSBuild

XML Schema and can be edited directly in Visual Studio so you can customize how the project is

loaded and compiled.

However, to edit the project file you need to effectively remove the project’s active status from the

Solution Explorer. Right-click the project you want to

edit in the Solution Explorer, and choose the Unload

Project command from the bottom of the context

menu that is displayed.

The project will be collapsed in the Solution Explorer

and marked as unavailable. In addition, any open

files that belong to the project will be closed while it

is unloaded from the solution. Right-click the project

entry again and an additional menu command will be

available to edit the project file (see Figure 45-10).

The XML-based project file will be correspondingly

opened in the XML editor of Visual Studio 2010, enabling you to collapse and expand nodes.

The following listing is a sample MSBuild project file for an empty C# project:

<?xml version="1.0" encoding="utf-8"?>

<Project

ToolsVersion="4.0"

DefaultTargets="Build"

xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<Configuration Condition=" ’$(Configuration)’ == ’’ ">Debug</Configuration>

<AppDesignerFolder>Properties</AppDesignerFolder>

<RootNamespace>ConsoleApplication</RootNamespace>

<AssemblyName>ConsoleApplication</AssemblyName>

<TargetFrameworkProfile>Client</TargetFrameworkProfile>

</PropertyGroup>

fiGure 45-10

922 .

chaPter 45 build cuSTomizATion

<Optimize>false</Optimize>

<OutputPath>bin\Debug\</OutputPath>

<DefineConstants>DEBUG;TRACE</DefineConstants>

<ErrorReport>prompt</ErrorReport>

</PropertyGroup>

<DebugType>pdbonly</DebugType>

<OutputPath>bin\Release\</OutputPath>

<DefineConstants>TRACE</DefineConstants>

<ErrorReport>prompt</ErrorReport>

</PropertyGroup>

</ItemGroup>

</ItemGroup>

<!-- To modify your build process, add your task inside one of the targets

below and uncomment it. Other similar extension points exist, see

Microsoft.Common.targets.

</Target>

</Target>

-->

</Project>

ConsoleApplication\ConsoleApplication.csproj

The XML contains the information about the build. In fact, most of these nodes directly relate

to settings you saw earlier in the Compile and Build pages, but also include any Framework

namespaces that are required. The first PropertyGroup element contains project properties that

apply to all build configurations. This is followed by two conditional elements that define properties

for each of the two build configurations, Debug and Release. The remaining elements are for project

references and project-wide namespace imports.

When the project includes additional files, such as forms and user controls, each one is defined in

the project file with its own set of nodes. For example, the following listing shows the additional

XML that is included in a standard Windows Application project, identifying the Form, its designer

code file, and the additional application files required for a Windows-based application:

MsBuild .

923

</Compile>

</Compile>

<Generator>ResXFileCodeGenerator</Generator>

设置

手机

书架

书页