William Bartholomew Developer Productivity Specialist Technology One
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
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.
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.
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.
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.