William BartholomewDeveloper Productivity SpecialistTechnology One

Multi-TargetingMulti-ProcessorRegistry AccessNew Loggers

Visual Studio version no longer “strongly bound” to the .NET Framework version.

Upgrading Visual Studio is now less risky. Allows selecting between:

.NET Framework 2.0 .NET Framework 3.0 .NET Framework 3.5 (“Orcas”)

Available from Visual Studio and MSBuild. Use new MSBuild features without

changing build outputs.

Toolset Choose between 2.0 or 3.5 Set via the ToolsVersion attribute of the

Project element Overridable via the MSBuild command-line

Target Framework Choose between 2.0, 3.0, or 3.5 Set via the TargetFrameworkVersion

property Overridable via the MSBuild command-line

http://blogs.msdn.com/msbuild/archive/2006/11/03/msbuild-orcas-and-multi-targeting.aspx

Initially set from the New Project dialog. Limits the set of project types available.

Change from the Project Properties dialog. Limits items available from the Add->New

Item dialog. Limits available references. Changing could result in warnings or

errors.

DEMO

By default MSBuild will use what is specified in the project file.

You can override the Toolset (2.0 or 3.5) with: /toolsversion:X.Y /tv:X.Y

You can override the Target Framework (2.0, 3.0 or 3.5) with: /p:TargetFrameworkVersion=X.Y

Need I say more? MSBuild command-line:

Disabled by default. Enabled with the /maxcpucount:X

argument. Shortcut is /m:X.

Visual Studio: Enabled by default (2 processors). Configurable via Tools->Options->Projects

and Solutions->Build and Run.DEMO

Won’t necessarily improve build performance: Test with it enabled and disabled. Experiment with different numbers of CPUs on

machines with > 2 CPUs. Optimised for performing multiple builds:

MSBuild processes are kept for 60 seconds to perform subsequent builds.

If only performing a single build disable with /nr:false.

MSBuild task builds sequentially by default. BuildInParallel attribute (Boolean) overrides this.

Provides a way to retrieve the value of a registry key without calling a task: $(Registry:<key name>[@<value

name>]) $(Registry:HKEY_LOCAL_MACHINE\

SOFTWARE\Microsoft\.NETFramework@InstallRoot)

Logs to “msbuild.log” in the current directory.

/fileLogger (or /fl) /fileLoggerParameters: (or /flp:)

LogFile=<Filename> Append Verbosity=<Verbosity> Encoding=<Encoding>

/fileLoggerParameters:LogFile=MyLog.txt;Append;Verbosity=diagnostic;Encoding=UTF-8

Similar to File Logger but creates a log file per “node” (processor).

Uses /fileLoggerParameters to configure.

LogFile is used as a template to which the node id is appended.

Creating a New Build Definition Workspace Mapping User Definable Location Retention Policies Editing Experience

Executing Builds Queuing Scheduling Continuous Integration

Command-Line Notification

No longer requires WorkspaceMapping.xml file.

Can be specified using GUI.Can copy an existing workspace.Probably one of the most important

settings to configure for a “large” repository.

Build definitions can now be stored anywhere in source control instead of under $/TeamBuildTypes/<BuildTypeName>.

Why do this? Store build types directly along the

projects they build. Improve build reproducibility. Simplify branching.

Specify how many builds should be kept by status: Succeeded Partially Succeeded Failed Stopped

Individual builds can be retained indefinitely.

Can only specify number of builds, not days. Can’t be based on build quality.

Build definitions can be edited via GUI rather than via TFSBuild.proj.

Most settings now stored in database and placeholders put in TFSBuild.proj for backwards compatibility.

Can be disabled.

DEMO

Builds submitted to a busy build agent are now queued rather than failing.

List of build agents are defined so machine names don’t need to be entered.

Build agents can be disabled. Can override drop folder when queuing a

build. Can specify priority. MSBuild properties can be passed

through.

DEMO

Build definitions can be scheduled to execute at a specific time on selected days.

Build will only execute if there are changes in the workspace. In Beta 2 you can force it to always build

even if there are no changes.

Automatically execute a build definition whenever a check-in occurs within its workspace. Each check-in queues a new build.

Or, accumulate check-ins. Check-ins are accumulated to reduce the

number of builds. User specifiable time threshold.

DEMO

Supports bulk deletion of builds. Choose between starting or queuing a

build (synchronous vs asynchronous). Supports building specific versions of

source-code rather than only the latest. Can override drop location, user the build

is requested by, and MSBuild properties. Builds can now be stopped from within

Visual Studio.

Notification tray icon to queue, monitor, and manage builds.

Similar to CCTray but much more powerful.

Will be released post-Orcas.Specification available at

http://www.slideshare.net/jimlamb/build-notification-applet.

“DEMO”build-notification-applet-24800.pdf