If you haven’t talked to me before, I am a serious fan of the Symbol Server and Source Integration in Team Foundation Server.  Recently, I thought about reducing the complexity of the entire story especially for those using Team Foundation Server.  You still have to have a file share available for symbols which is just something else to have to request, manage, deal with for disaster recovery, and is particularly problematic when users are in geographically remote offices.  Individual developers also have to manually register the symbol server in the Visual Studio options for each of the development machines they ever use.  Why though?  It shouldn’t be this difficult especially when you have already adopted TFS.

I submitted a new feature request on the Visual Studio Team Foundation Server product team’s User Voice site specifically for assisting with this complexity.  I would like TFS just to be treated like an enterprise symbol server and Visual Studio can just take advantage.  My good friend and colleague, Adam Cogan, encouraged me to share with my blog readers more details about this feature request.

I would also like to ask for your help with voting on the feature request if you like the idea and would be important for your team & organization.

VOTE HERE

Additional Details for the Feature Request

Version Control Folder to Hold Symbol Server Files

The main part of this would be something like a version control folder to hold the symbol server files such as $/Symbols.  This would be a special folder that would only be used for Symbols.  You would then be able to have a URL endpoint that TFS recognizes and handles appropriately (i.e. https://tfs.myserver.com/tfs/DefaultCollection/Symbols).

With this type of feature in TFS you can take advantage of many side benefits including:

· No file share to worry about getting provisioned by IT or backed up

· Takes advantage of TFS Proxy caching for geographically distributed locations

· This could be a special version control folder type where it doesn’t have to keep history – only the latest version (T)

· Would work out really well for those using TFS on Azure (especially with on-premises build servers)

· Potentially Symbol Server for CodePlex projects!

· IntelliTrace & the VS Profiler benefits greatly from this as well!

Automatic TFS Build Configuration

If this feature is setup & configured, then why not just go ahead and auto-configure new TFS build definitions as well?  Pop it right in there…

Automatic Client-Side Configuration

If I connect to a Team Project Collection, I want my Visual Studio (and other clients that use symbol server) to be auto-configured for the symbol server to be used.  It should just be automatic!  This would be very similar to how the client auto-configuration for TFS Proxy just works for anyone doing a version control get.

Build Retention Policies

If you have symbols turned on for TFS builds to handle when retention policies are run, you could configure it to either destroy or delete the symbols from the special version control folder.  As an administrator, I may want to actually destroy the symbols with retention policies for some of my build definitions just to save on space.

Help me everyone out with your votes!

Ed Blankenship

Updates – I plan on making updates to this blog article from time to time as I learn more and changes are made to TFS & SmartAssembly to smooth out some of the rough edges.  Come back again for the latest & greatest!

I really like tools that provide assistance with the release management & maintenance cycles of ALM.  I think some of the features really add a particular shine to your application.  It’s something that I’m currently writing an article about but I wanted to share how to integrate one of those tools into your Team Foundation Server 2010 Build Process.  This first tool to be reviewed is Red Gate’s SmartAssembly product.

SmartAssembly is a product that can help you out with obfuscation if you need it but I primarily want to focus on two of its other major features:

• Automated Error Reporting – When an exception occurs, the end user can be prompted to send back the exception details so that the development team can review those details.  This can also work with server-side & web applications without requiring end user prompting.
• Feature Usage Reporting – This is essentially telemetry for your application to figure out how your users are using the application so that you can make good decisions in the future about where to invest for future releases.  It does this by sending back anonymous data for users who opt-in at runtime.  It will even automatically send back data about the machine the software is being run like the operating system.  This can be extremely useful data to product managers.

You don’t have to worry about any of the details because once you run your assemblies through SmartAssembly, it instruments all of the necessary functionality automatically for you.  If you acquire the Professional edition, you can customize the reporting experience including the ability to host your own web server to accept the error & feature usage reports.

Aside :  Too many teams & companies have blindly adopted obfuscation for their assemblies in the past without taking into consideration the true “total cost” of obfuscating your applications.  I’m all for obfuscation where it makes sense to protect IP as long as the value of the protection of that IP is worth more than the extra cost, resources, and maintenance complexity to truly support an obfuscated product.  Each team & company is going to have to make that decision based on the resources available and the value of the IP to be protected  – just don’t go into it blindly.

FYI – PreEmptive’s Dotfuscator tool is a competing product line with a similar feature set that I hope to be covering in a future blog post.

Ignoring obfuscation, these two features are absolutely great for gaining visibility about your application once it has been released.  For all of those teams that aren’t traditional software vendors but building applications for internal use, these are great features for those applications as well.  Software engineering teams building internal applications are very much in need of the same type of information as ISVs about how their internal “customers” are interacting with their applications.  Internal applications don’t necessarily need obfuscation but they can definitely benefit from automated error & feature usage reporting!

One part that I absolutely love about SmartAssembly is that even though the tool instruments and changes your assembly, it also provides the ability to produce a set of matching symbols (.PDBs) that are extremely important for several scenarios in TFS, the Visual Studio ALM family of tools, as well as basic debugging.

I am going to be spending some time in this blog article to walkthrough how to integrate SmartAssembly into your automated TFS build process so that your teams can take advantage of these features.  I am going to take the approach of not creating any custom workflow activities for this particular effort.  Jim Lamb has a good discussion about when to make customizations to the MSBuild file (essentially the Visual Studio project file) and when to make your customizations in the Windows Workflow-based build process template.  As much as I very much prefer customizing my build process templates using custom workflow activities, in this case I choose to do a little customization of both without using any custom workflow activities.  I would much rather have done this using only native Windows Workflow activities but I’ll talk more about that a little later.

Disclaimer:  As a Microsoft MVP, I have been a part of the Friends of Red Gate group for the last four years and I have been provided Not For Resale licenses of the Red Gate family of products though I reserve the right to offer unbiased opinions and criticisms.  I was not paid for these contributions.  However, I may or may not get a complimentary round the next time I see the Red Gaters at the pub in Cambridge.

Works on My Machine Disclaimer:  Everything in this blog article works on my machine when I wrote it.  I have the latest version of SmartAssembly and TFS 2010 installed & configured correctly.  I’ve done my best to make this as reusable as possible for most team’s scenarios but I can’t tell you that it will work for you.  Hopefully it gets you started on the right path though!  Please don’t contact me and let me know that my code killed your cat.  I feel for you… I do – I just can’t do anything about it.  You’ve been warned.  I take the same approach that Scott does with blog contributions.

Configuring SmartAssembly for Team Use

SmartAssembly has actually been designed out of the box to handle the single-developer team scenario.  If you are using TFS, you are likely not a single-developer team so you’ll want to a few things to get SmartAssembly setup for use with a team.  The architecture for SmartAssembly can best be described with this architecture diagram:

Source:  http://www.red-gate.com/products/dotnet-development/smartassembly/team-package

You’ll need to get the Professional edition of SmartAssembly since it allows you to store everything in a shared SQL Server database.  One nice thing is that each developer who will need to interact with error & feature usage reports only needs a Developer edition license instead of a full Professional edition license.  You’ll need to install & configure the Professional edition on each of your build servers.  You might as well go ahead and create a build agent tag called “SmartAssembly” to indicate which build agents in your build farm are hosted on servers that have SmartAssembly installed.

When you first start SmartAssembly, you will want to setup the desktop machines & build servers to use the same SQL connection settings for the shared SmartAssembly database.  I even like to use the friendly TFS DNS names that I already have setup for my particular TFS environment.  Remember that if you are using the limited use license of SQL that is included with TFS, you won’t be able to house the SmartAssembly database on that instance.  You’ll need to purchase a legitimate SQL Server license.  It’s a great time to upgrade to the SQL Enterprise edition if you can for TFS!  TFS will definitely take advantage of several of the features.

It is pretty easy to setup from there:

Be sure to also indicate that you want to use relative paths.  Relative paths will be very important when you are using it in a team environment with Team Foundation Server.

BTW, if you need to setup SmartAssembly to use SQL Authentication instead of Windows Authentication, you can do that using this particular article. You do this by basically updating the settings configuration file available on a Windows 7 machine at C:\ProgramData\Red Gate\SmartAssembly\SmartAssembly.settings.

Creating & Storing the SmartAssembly Configuration File in Version Control

I am going to make this easy by just using a quick Windows Forms application however you are able to process any type of assembly including Silverlight apps, ASP.NET web applications, class libraries, etc. using SmartAssembly.

You will want to compile your assembly at least once and then start a new SmartAssembly project.  It actually doesn’t matter where the source & destination location of the assembly is set to in the configuration but you might want to pick a location that all of the developers will be using.  Don’t worry about the build server locations because we will override those later in the build process!  To keep it simple, I’m only going to enable the following features in my SmartAssembly configuration file:

• Automated Error Reporting,
• Feature Usage Reporting, and
• Generate Debugging Information

You can research more on the other options that are available but I am going to keep this walkthrough very simple.  Once you are satisfied with your settings, click the “Save As…” button and save the configuration file in the same folder as your Visual Studio project file.  I even like to include the file in my Visual Studio project so that I can work with it and check it into the version control repository along with the rest of my project.  The SmartAssembly configuration file has a “.saproj” file extension.

The next thing you might want to do is open the configuration file using the XML Editor in Visual Studio to verify all of the settings look correct. You can use the “Open With…” context menu command from the Solution Explorer window to help you out.

The main thing you want to do is be very mindful of using relative file paths everywhere in the configuration file since the location of the source code location changes on the build server & developer machines.  For example, TFS Build allows you to have multiple build agents running on any build server.  I might have three build agents on a build server which means three builds could be running at any given time on the build server.  You isolate each build agent on a build server by setting the working directory to something that will be a unique value.  The default setting is $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionName) but I usually change it to $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionId) to give me a few extra characters since we also have path length limitations to go up against.

Defining Custom MSBuild Properties

At this point, we are going to define a few custom MSBuild properties that we are going to use to trigger the SmartAssembly functionality.  The table lists the properties I am going to define in this process.

Modifying the Visual Studio Project Files

For many of the common project types, Visual Studio project files are in fact actually MSBuild scripts under the covers.  What we are going to do is add some custom functionality at the end of the project file that we will later “turn on” during the build process.  You could modify this so that you could “turn on” the functionality at development time locally but this additional script excerpt will leave it turned off during normal development.

To edit a Visual Studio Project file, you can “unload” the project from the context menu in Solution Explorer and then double-click it to open it in a new editor document window.  You will add the following excerpt close to the bottom of your Visual Studio project file just before the final </Project> ending tag. In my case it is a .csproj file.

<!-- Red Gate SmartAssembly Custom Post-Compile Processing for TFS Builds -->
<UsingTask TaskName="SmartAssembly.MSBuild.Tasks.Build" AssemblyName="SmartAssembly.MSBuild.Tasks, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7f465a1c156d4d57" Condition="'$(TfsBuild)' == 'True' and '$(RunSmartAssembly)' == 'True'" />
<PropertyGroup Condition="'$(TfsBuild)' == 'True' and '$(RunSmartAssembly)' == 'True'">
  <!-- Uncomment this next line if the configuration file is not located in the same directory and uses the same name as the project. -->
  <!--<SmartAssemblyConfigurationFileRelativePath>SmartAssemblyConfigurationFileName.saproj</SmartAssemblyConfigurationFileRelativePath>-->
  <!-- This will set the default name of the configuration file to the same name as the project name if the property is not defined elsewhere. -->
  <SmartAssemblyConfigurationFileRelativePath Condition="'$(SmartAssemblyConfigurationFileRelativePath)' == ''">$(ProjectName).saproj</SmartAssemblyConfigurationFileRelativePath>
</PropertyGroup>
<Target Name="AfterBuild" Condition="'$(TfsBuild)' == 'True' and '$(RunSmartAssembly)' == 'True'">
  <!-- Archiving the original compiled assembly and matching debugging symbols file. -->
  <Message Text="Archiving the original compiled assembly and matching debugging symbols file." />
  <Copy SourceFiles="@(_DebugSymbolsOutputPath)" DestinationFolder="$(OutDir)Original" Condition="'$(_DebugSymbolsProduced)' == 'true' and '$(CopyBuildOutputToOutputDirectory)' == 'true' and '$(SkipCopyBuildProduct)' != 'true'" />
  <Copy SourceFiles="@(MainAssembly)" DestinationFolder="$(OutDir)Original" Condition="'$(CopyBuildOutputToOutputDirectory)' == 'true' and '$(SkipCopyBuildProduct)' != 'true'" />
  <!-- Process Assembly through SmartAssembly -->
  <SmartAssembly.MSBuild.Tasks.Build ProjectFile="$(SmartAssemblyConfigurationFileRelativePath)" Input="@(MainAssembly)" Output="@(MainAssembly)" OverwriteAssembly="True" />
</Target>

It is a modified version of the snippet from the SmartAssembly help documentation for integrating with MSBuild:  http://www.red-gate.com/supportcenter/Content/SmartAssembly/help/6.5/SA_UsingSmartAssemblyWithMSBuild.  You’ll see a little later where we are going to “turn on” the functionality by editing the TFS build process template.  If you named your configuration file the same name as the project name and stored it in the same location in version control you actually don’t need to modify anything in the snippet at all.

Notice that the snippet keeps the original copies of the assemblies and matching symbols (.PDB) file so that they later get copied to the TFS build’s drop folder.  It is copying the original assembly and matching symbols into another subdirectory named “Original” instead of just outputting the SmartAssembly instrumented assembly & matching symbols to a subfolder called “Obfuscated”, “Instrumented”, or “Protected.”  I used to use the latter approach (as some people suggest) but if you are also compiling installers, it is useful to create an installer during specific builds that include the original assemblies instead of the instrumented ones.  In my installer definition (like a WiX file) I’ll just refer to the regular location and it will pickup whatever version the build process created.  If I want an installer to have the original assemblies then I just queue a new build and will set the SmartAssembly process parameter to false for that build.  I don’t have to do anything additional in my WiX definition files to handle this scenario. 

Another side effect you get by using this approach is that if your build process runs any automated tests, static code analysis, test impact analysis, etc., then it will use the instrumented versions of the assemblies as the target of the tests and other post-processing tools!  There are several ways to skin this particular cat but I have fallen back to this approach after a few years of dealing with these issues.

Modifying the Build Process Template in Windows Workflow Foundation

Technically, we could just hard-code the extra MSBuild process parameters that we need using the default TFS build process template on the Process tab of the build definition editor window:

If you are okay with this approach then you don’t really need to go any further.  However, we could make this a richer experience for people who will edit and queue these builds from day to day.  This is where we can go through and create a custom process template.

The first thing you will want to do is create a new build process template to start your customizations.  I have included mine for download at the end of this blog post but you may want to walk along.  I usually start by creating a copy of the default build process template available from TFS.  If you aren’t familiar with the basics of this particular process, I would highly suggest going through the walkthrough in either of these books:

• Chapter 16 – “Customizing the Build Process” -  from Professional Team Foundation Server 2010 by Wrox (Wiley) – Authors:  Ed Blankenship, Martin Woodward, Grant Holliday, and Brian Keller
• Chapter 16 – “Process Template Customization” – from Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build - Second Edition by Microsoft Press – Authors:  Sayed Hashimi and William Bartholomew

You can then change your build definition over to the newly copied build process template using the following combo box.

If you click on the hyperlink, it will take you to the location in Source Control Explorer where you can get the latest version into your workspace and then open the build process template file for editing in the Windows Workflow Foundation Designer.

Defining Build Definition Process Parameters

The first thing we can do is specify a new build process parameter that is exposed to the end user of the builds by going to the “Arguments” tab in the lower left-hand corner of the Workflow designer.

I am going to create a Boolean process parameter simply named “RunSmartAssembly” and set the default value to False.  This isn’t an MSBuild property but a workflow process parameter that will be exposed to the end user when they are queuing a new build or when editing the build definition.

This next step is just to make things that much nicer.  We can give the TFS Build system some additional metadata to make sure the parameter is exposed to the end user in a nice fashion.  There are more details about the process parameter metadata field in either of the book chapters mentioned above in case you would like to learn more!  You edit the collection information for the Metadata parameter that is already defined in the default build process template.  (It’s two above the parameter we created in the previous screenshot.)  Just click the ellipsis button in the default value field column to open up the metadata editor window.

Fill out the details as indicated above and save your build process template. You won’t see the changes immediately if you were to go back to the build definition editor because we haven’t checked-in the build process template back to the version control repository yet.

Verify SmartAssembly is Installed on Build Server

Whenever I architect a build that requires the use of a custom tool and it isn’t stored in version control (or even if it is but someone forgot to add that workspace mapping) I usually want to add a check in the build process to make sure that the tools are actually available to the build server.  If the check doesn’t locate the tool I have it give a nice build error.

Add an If workflow activity inside the Build Agent Scope activity (labeled “Run on Agent”) but before the section that starts the compilation.  It doesn’t exactly matter where as long as you get them in the agent scope but before any type of compilation begins.  I am going to set my condition to something like the following:

RunSmartAssembly AndAlso Not System.IO.File.Exists(String.Format("{0}\{1}\{2}", Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), "Red Gate\SmartAssembly 6", "SmartAssembly.exe"))

You can then add a Write Build Error activity with an appropriate message to indicate that SmartAssembly was not found.  It should look something along the lines of this following example.

Appending Additional MSBuild Properties

We can now work on passing in the additional MSBuild properties.  I’m going to do this in two steps.  The first step is to append the TfsBuild MSBuild property to the pre-defined workflow variable that is used for this purpose named MSBuildArguments.  I’m going to do this immediately after the workflow activities we added for the previous step using another native primitive workflow activity:  Assign.  It’s a super simple activity that is great for this particular purpose.  The assignment expression that I am going to use for the Value parameter is:

String.Format("{0} {1}", MSBuildArguments, " /p:TfsBuild=True")

After that, we will add another If activity where the conditional will be set to the RunSmartAssembly workflow parameter we created earlier.  We will also add add another Assign activity and append our remaining MSBuild property to pass into the compilation process.  You can use this assignment expression for the Value parameter of the Assign activity:

String.Format("{0} {1}", MSBuildArguments, " /p:RunSmartAssembly=True")

The final sequence looks similar to the following screenshot.

You may be asking “Why did we define the $(TfsBuild) MSBuild property when we could have just used the $(RunSmartAssembly) property?” That’s a great question… You don’t need it if you aren’t going to do any additional customization. However, in general, I like to always define the $(TfsBuild) MSBuild property so that you could customize the project files to modify the conditions based on whether it is occurring during a TFS Build or if it’s occurring on a developer’s machine. It’s quite handy when you need it.

Notice that we are also performing all of the SmartAssembly processing steps before the Source Server Indexing and Symbol Server Publishing phase of the build process so that both the original symbols and the symbols that match the instrumented assemblies are published correctly to Symbol Server and have the appropriate indexing for Source Server support included in those symbols.  That will be extremely useful later whenever you need to debug against either the original or instrumented assemblies in the future.  You can also open IntelliTrace log files & take advantage of Test Impact Analysis if you keep obfuscation turned off in the SmartAssembly configuration.

Finale

That’s it!  Just save the changes to your build process template and check the file into the version control repository so it can now be used by your build definitions.  Be sure to set your new custom workflow parameter to True and then queue a new build!

You’ll now notice that it runs correctly even if you have defined for your build process to compile multiple build configurations (i.e. Debug | x86, Release | AnyCPU, etc.)

Potential Improvement Areas

• Licensing & Activation for Build Servers – Unfortunately, the way SmartAssembly is licensed you have to purchase a license for each of the build servers you might have and activate the software on those build servers.  The accompanying side effect is that the developer licenses are cheaper.
  This can be problematic in a TFS environment where you might have a build farm that has one build controller with 20 build servers that have three agents on each of those build servers.  It’s not that SmartAssembly would be used at the same time on all 60 of those build agents but you also don’t know which build agent will be reserved for a particular build at any given time.  I have resorted to using the build agent tagging feature of TFS Build to handle making sure particular builds only reserve an agent with SmartAssembly configured & activated.  However, this causes a complete underuse of the hardware resources available in a build farm. 
  I would rather tool vendors achieve their revenue targets by increasing the per-user license fee because and specifically for users who benefit from the advantages that the particular tool brings to them. This licensing model if very similar to how the Visual Studio & third-party components licensing model works.  Microsoft and other third-party component vendors give you the ability to install and use the their tools on a build server without charge.
  I consider build agent machines throw-away machines.  They should remain completely clean but don’t need to be backed up or monitored.  I usually will have a virtual machine base image that has everything already installed & ready to go so that I can add/remove to the build farm “pool” as needed.  I even prefer to throw away machines after 30 days and bring new build agents online to ensure the whole build farm is kept as clean as possible.  When you have tools that require activation & licensing, this scenario quickly becomes problematic.  This leads me to another potential area for improvement.
• Installation on Build Servers – If you know me well, this is a slightly less critical criticism than the first bullet point but also a pretty big pet peeve of mine.   If you make tools, please don’t require them to be installed on the build server. It’s another thing that has to be kept up to date on potentially many machines and in a base system image.  I would rather be able to check them into a known version control folder and then have the build servers download the latest version during the build process.  There is even a supported mechanism in TFS Build that allows the build controllers & agents to watch for custom assemblies & tools and whenever it notices a new version of those assemblies then it gracefully updates all of the machines in the build farm automatically.  This allows team members to focus & introduce changes to the tools using version control instead of having to update the base image of the build server every time there is a new update.
  You also benefit from having full auditing of what exact tools version were used to produce a specific set of assemblies.  That allows you to potentially recreate a build you created a year ago by simply specifying what version of the source code (including build tools) to use during that build process.
• Native Workflow Activity for TFS 2010 Build Process Templates -  The process I described in this blog article is definitely much more difficult than what it could be.  Instead of introducing customizations in the MSBuild-portion of the TFS build process, I much rather prefer dropping in a native workflow activity after the compilation process.  SmartAssembly unfortunately doesn’t have a custom TFS build workflow activity at this time.  I would love to see one that allowed me to specify multiple assembly inputs for each build configuration that occurs in the build process and then the appropriate SmartAssembly configuration file for each of the assemblies.  You can do some nice things with it to really make this process super easy.
• Database Endpoint Instead of a Web Service Layer – SmartAssembly requires the entire team to have access to the centralized database to manage the automated error & feature usage reports.  The software makes direct database calls instead of going through a service layer is which is very different from the way that tools built for TFS are designed in general.  This can be problematic especially if you have TFS setup for your team to be able to access remotely over HTTPS (port 443) without the use of a VPN.  Several IT organizations,really don’t want to open their database ports or even give access to production database instances.  My suggestion would be to have an intermediate service layer that can “integrate” with the existing TFS IIS web sites.  This allows the tool’s service layer to piggy back on the existing infrastructure already setup for TFS.  If you have an SSL certificate and HTTPS configured, then you can take advantage of it.  If you have load balancing setup for scalability, then you could potentially leverage that as well!  We did this with our Notion Timesheet for TFS tools and one of the benefits we end up getting is that we are able to access the service layer from anywhere we can access TFS including over the Public Internet.  No worries about giving people access to the SQL Server instance as well.
• Source Server Support – This isn’t necessarily a TFS-specific topic but really something for anyone using build servers & Source Server indexing.  When you compile on a build server, the location of the source code is included in the symbol information.  Your developers will normally not download the source code to the same location as other developers and particularly not the same location that the build server does since that changes depending on what TFS build agent is used on a build server for any particular TFS build.  Source Server Indexing helps to combat this particular problem by replacing the physical location with the location in the version control repository including the branch and version of the code used.  SmartAssembly has a feature that allows you to review details of stack trace, object values, etc. when you open an error report.  However, it doesn’t use the Source Server information even if it is stored in the symbol files.  This is particularly a problem when you are in a TFS environment and using automated builds.  SmartAssembly just ignores those additional streams in the symbols file.  SmartAssembly should use the Source Server information if it exists in the symbols to pull the appropriate version of source code from the version control repository.  (Red Gate Support Ticket Number:  F0041570)
• Additional ALM Integration with TFS – There are so many different areas where SmartAssembly could shine if it had some additional ALM-specific integration with TFS!

Download Process Template

If you are interested in downloading the completely customized version of the build process template, I have included a link to it below.

Download SmartAssembly Process Template

Take care,

Ed Blankenship

I wanted to wring my hair on this one… but it was actually rather simple to get solved.  I’m helping a customer this week upgrading their server to TFS 2010 from TFS 2008.  They had TFS 2008 builds compiling & publishing Visual Studio 2008 solutions & builds.  When you upgrade to TFS 2010, those existing build definitions will end up using the UpgradeTemplate.xaml build process template in TFS 2010.  Not a problem there.  This customer was not able to upgrade their solutions & projects immediately to Visual Studio 2010 in tandem with the TFS 2010 upgrade.  That should normally not be a problem but having done a few of these upgrades, I know that I usually need to set out some time just to get the existing builds working again.  There’s always something wrong.   Never huge but enough to irritate you after an upgrade.

We went through a few hurdles to get those solutions & projects compiling and then we moved on to the deployment builds.  They seemed to just work which was great!  In their legacy TFSBuild.proj files, they had an entry in the AfterCompile MSBuild target essentially like this:

            <
            MSBuild Projects="$(SolutionRoot)\Branch\ClickOnceProject.csproj" 
Properties="PublishDir=\\FILESERVER\ClickOncePublishPath\;ApplicationVersion=$(VersionNumber);"
Targets="Publish" />

It was great until we went to go actually fire up the app… CRASH!  It is complaining in the ClickOnce deployment log that the deployment manifest wasn’t semantically valid and that the deployment manifest was missing the <compatibleFrameworks> node.  Here’s the full (redcated) log: (emphasis mine)

PLATFORM VERSION INFO
    Windows             : 6.1.7601.65536 (Win32NT)
    Common Language Runtime     : 4.0.30319.239
    System.Deployment.dll         : 4.0.30319.1 (RTMRel.030319-0100)
    clr.dll             : 4.0.30319.239 (RTMGDR.030319-2300)
    dfdll.dll             : 4.0.30319.1 (RTMRel.030319-0100)
    dfshim.dll             : 4.0.31106.0 (Main.031106-0000)

SOURCES
    Deployment url            : http://webserver/ClickOnceProject.application
                        Server        : Microsoft-IIS/6.0
                        X-Powered-By    : ASP.NET
    Application url            : http://webserver/Application%20Files/ClickOnceProject_1_1_1_1/ClickOnceProject.exe.manifest
                        Server        : Microsoft-IIS/6.0
                        X-Powered-By    : ASP.NET

IDENTITIES
    Deployment Identity        : PolicyManagement.application, Version=1.11.1026.3, Culture=neutral, PublicKeyToken=3801d6f74f2e8cd7, processorArchitecture=x86
    Application Identity        : PolicyManagement.exe, Version=1.11.1026.3, Culture=neutral, PublicKeyToken=3801d6f74f2e8cd7, processorArchitecture=x86, type=win32

APPLICATION SUMMARY
    * Online only application.
    * Trust url parameter is set.
ERROR SUMMARY
    Below is a summary of the errors, details of these errors are listed later in the log.
    * Activation of http://webserver/ClickOnceProject.application  resulted in exception. Following failure messages were detected:
        + Deployment manifest is not semantically valid.
        + Deployment manifest is missing <compatibleFrameworks>.

COMPONENT STORE TRANSACTION FAILURE SUMMARY
    No transaction error was detected.

WARNINGS
    There were no warnings during this operation.

OPERATION PROGRESS STATUS
    * [10/26/2011 1:49:41 PM] : Activation of http://webserver/ClickOnceProject.application has started.
    * [10/26/2011 1:49:42 PM] : Processing of deployment manifest has successfully completed.
    * [10/26/2011 1:49:42 PM] : Installation of the application has started.
    * [10/26/2011 1:49:42 PM] : Processing of application manifest has successfully completed.

ERROR DETAILS
    Following errors were detected during this operation.
    * [10/26/2011 1:49:43 PM] System.Deployment.Application.InvalidDeploymentException (ManifestSemanticValidation)
        - Deployment manifest is not semantically valid.
        - Source: System.Deployment
        - Stack trace:
            at System.Deployment.Application.PlatformDetector.VerifyPlatformDependencies(AssemblyManifest appManifest, AssemblyManifest deployManifest, String tempDir)
            at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
            at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc)
            at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
            at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
        --- Inner Exception ---
        System.Deployment.Application.InvalidDeploymentException (InvalidManifest)
        - Deployment manifest is missing <compatibleFrameworks>.
        - Source:
        - Stack trace:

COMPONENT STORE TRANSACTION DETAILS
    No transaction information is available.

Now what I remember is that the <compatibleFrameworks> node was actually introduced in the deployment manifests for .NET / ClickOnce 4.0 in Visual Studio 2010 and we shouldn’t be expecting them for Visual Studio 2008 ClickOnce projects.  Sounds like the build process is not picking up the right version.  In the TFS 2010 version of the TeamFoundationBuild.targets file, it handles compilation correctly by setting the appropriate MSBuild tools version number.  Why wasn’t it picking that up for our publish?

Oh yeah… since TFS 2010 build had to specify it for the legacy UpgradeTemplate.xaml and TeamFoundationBuild.targets files, we have to do the same thing.  Duh.  It ended up being an easy fix and we just updated that portion of the legacy TFSBuild.proj build script to explicitly set the MSBuild tools version and pass in the framework version as well for the ClickOnce project.

            <
            MSBuild ToolsVersion="3.5" Projects="$(SolutionRoot)\Branch\ClickOnceProject.csproj"
 Properties="ClrVersion=2.0.50727.0;PublishDir=\\FILESERVER\ClickOncePublishPath\;ApplicationVersion=$(VersionNumber);"
 Targets="Publish" =""/>

BTW – you can do this in the new Windows Workflow-based build process templates as well but instead you would use the MSBuild workflow activity.

However, I would highly suggest upgrading to Visual Studio 2010 when you get a chance since it will handle ClickOnce projects that target .NET 2.0, .NET 3.0, .NET 3.5, and .NET 4.0 seamlessly.

Now that all of the legacy TFS 2008 builds are working in TFS 2010, it’s time to start helping my current customer get their Visual Studio 2008 solutions & projects upgraded to Visual Studio 2010 and leverage the new Windows Workflow-based build process template!

Ed Blankenship

Many thanks to Josh Winfree for helping out with the discover of this one!

I’m pretty excited about being in Austin this week (one of my favorite cities) and while I’m here, I’m going to be speaking at the Austin TFS User Group this Thursday night.  Here are some more details:

Special Event: TFS 2010 Build Customization with Ed Blankenship

Date: Thursday, August 4th, 6:30 to 8 PM at Overwatch Systems, 5301 SW Parkway

To attend please register at: http://tfsaustinbuild.eventbrite.com/

Don't miss this one-time event and deep dive on "Customizing the Build Process with TFS 2010 Build and Workflow Foundation." In TFS 2010, the automated build infrastructure has been revamped to use Windows Workflow Foundation (WF) instead of MSBuild. Ed will present and answer questions on how to customize the default build process template and how to leverage multiple aspects of the workflow implementation for TFS 2010 Build.

Location:

Overwatch Systems, 6:30 to 8 PM

NOTE: park in the parking garage, signs will direct you to the meeting

5301 Southwest Parkway

Austin, TX 78735

Looking forward to seeing everywhere in the area there!

Ed Blankenship

Wow – I’ve been seeing the discussions in the last few weeks from the team members but I’m happy to announce that they have done a great job and released the first release of the Community TFS Build Extensions on CodePlex!  There have been several months of effort put into putting this collection together and you’ll see some of the best contributors that are available.   You’ll find all sorts of custom build activities and there are many more included on the backlog.  Be sure to vote for you favorite.  The best part of this CodePlex project is that the source code is fully available for your use internally.

Release Notes

• This is our first Stable release providing in the region of 100 Activities / Actions
• This release contains assemblies and a CHM file.
• We anticipate shipping every 2 to 3 months with ad-hoc updates provided to the documentation.
• We welcome your candid and constructive feedback and look forward to improving the quality with and for you.
• Please use the Discussion and Issue Tracker tabs for providing feedback.

The Visual Studio ALM Rangers have also released a set of guidance documents for customizing builds in TFS 2010 including the use of the Community TFS Build Extensions.  Check out more details here:  http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/06/17/toc-build-customization-guide-blog-posts-and-reference-sites.aspx

If you are looking for a book with information about how to customize build definitions, check out Professional Team Foundation Server 2010 as well which goes through one example which uses an activity from the Community TFS Build Extensions to stamp the version number on assemblies.

Ed Blankenship

With the Lab Management features of Visual Studio 2010 and Team Foundation Server 2010, you can create a build definition that deploys a build to a virtual environment being managed by Lab Management.   However, it doesn’t work if you have setup a physical environment that is being managed by Lab Management.

FYI – If you don’t have servers to host Hyper-V machines you can create “physical environments” and register them for use with Lab Management.  This allows testers to run tests and collect information coming from those physical environments just as they would from the virtual environments.  This is a good intermediate step for those organizations wanting to take advantage of Lab Management, haven’t invested in the virtual infrastructure necessary, and want to leverage existing physical environments (like QA, DEV, Staging, etc.).

Darshan, from the Lab Management product team at Microsoft, released a new build process template (XAML) file that adds limited support for deploying to physical environments and is similar to the standard deploy build process template available out of the box.  However, there are some shortcomings in that implementation including not being as rich of an experience since it doesn’t use a custom designer.

Not a problem… Colin Dembovsky who is one of our newer ALM/TFS Consultants at Notion Solutions helping customers in South Africa has put together a Lab Management deploy build process template for physical environments that attempts to address those shortcomings and provides for a rich experience that is similar to the experience that is used for deploying to virtual environments.

Check it out!  http://colinsalmcorner.blogspot.com/2011/02/build-deploy-test-workflow-for-physical.html

Ed Blankenship

As Jim Lamb announced in June 2009, TFS 2010 introduces support for Source Server and Symbol Server as part of the default automated build process template. This is a really key feature addition but I have found that many developers ask about why it would be so important and why it would help them. Ultimately, we are starting to have more and more tools that need access to the symbol file information and the original source code that was used for compilation. For example, some of the tools that come to mind are:

• Visual Studio Debugging including the Remote Debugger
• IntelliTrace
• Visual Studio Profiler
• WinDBG

By setting up Source Server and Symbol Server support during your build process, you’ll be able to work with assemblies & executables that come from the build servers and still use tools that need information from them.

What are Symbols?

John Robbins has an excellent blog post to get started about learning what symbols are titled: “PDB Files: What Every Developer Must Know.” I highly recommend you take a moment to read through it.

So to summarize from John’s article, the symbol files are the .PDB files that match a particular assembly and contain important information that’s necessary for debugging tools. Specifically for .NET assemblies, the symbol files include:

• Source File Names and Line Numbers
• Local Variable Names

He also reminds us one very important statement about symbol files: “PDB files are as important as source code!” That is absolutely true! I cringe any time I hear from a developer that says “oh, those .PDB files take up so much space so I’m going to delete them.” Ouch – The sad thing is those are developers that keep people like John in business whenever they run into problems in production. Save yourself some time, money, and effort and keep your symbol files around. Not to say that John doesn’t earn every penny but I’m sure his life is much better whenever you do have your symbols!

This is exactly where Symbol Server helps out. Essentially, the Symbol Server is a central location for your company that keeps the .PDB files for you. Therefore, you can install your application (without symbols) that was compiled from a build server and whenever you want to use a debugging tool like Visual Studio, it will know how to contact the Symbol Server location to get the matching set of symbols. More about how to configure Visual Studio to look for a Symbol Server further down in this blog post.

John also mentions how to manually perform the steps necessary for completing the loop with Source Server and Symbol Server. Thankfully, since you are using TFS 2010 Build, you don’t have to go through those steps. The functionality is included in the default build build process template (but not the Upgrade Template).

Aside: If you are performing obfuscation using your favorite .NET obfuscation utility, you will want to make sure you produce symbol files that match the newly created assemblies. This is because the variable names and other information change by the obfuscator. What I will normally do will do is keep both the original assemblies with their matching symbol files in addition to the obfuscated assemblies with match symbol files. I store the artifacts for the obfuscated assemblies in a sub-folder called “Obfuscated.”

How to Setup Symbol Server

A common misconception about Symbol Server is that you actually have to set up a server and install the Symbol Server software. Not at all! All you have to do is setup a file share on another server. If you are using my suggestion about using friendly DNS names with TFS, you might extend that for the symbol server as well:

\\symbols.contoso.local\Symbols

On my particular demonstration machine, I have a local file share that contains some of the symbols that were published from my TFS 2010 Builds:

How to Configure Build to Index for Source Server and Publish to Symbol Server

Configuring the build definition to use the new Symbol Server location, couldn’t be easier. Open up the build definition editor and navigate to the Process tab. There, you will see all of the process parameters. If you are using the default build process template then you will find the Source Server and Symbol Server settings underneath the “2. Basic” category as shown below.

The build process will then do all the work for you!

Source Server Indexing

What actually happens when the build process is actually running it’s Source Server indexing? Let me first start by discussing the problems with symbols that come from a build server (or another machine.) One of the pieces of information that is stored inside of the symbol file is the location of the original source file that was used for compilation into the assembly you are debugging. This can be a problem because for my particular case, the local location of the source code file on the build server is:

C:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\Form1.cs at version 32 from the MAIN branch

Not only do you to have put all of the source files in the same exact spot but you would have to get it from the right branch and even the exact same changeset version from the TFS version control repository. That’s a lot of manual work… This is where the indexing for Source Server helps you out. You’ll also notice that if you are producing symbols from your obfuscation utility, those can indexed for Source Server support as well.

When the TFS 2010 Build runs the source indexing for Source Server, it writes an alternate stream of information in the symbol files that will provide the following information for each source file:

• Source Control provider’s information and the command-line utility to use to get the file (In our case that would be using tf.exe)
• Full TFS Version Control Repository Server Path including the branch name
• Version

The default build process template uses the srctool.exe command-line utility first to list all of the local source file locations that are stored in the symbol file. Then, it generates a temporary file that contains the exact alternate stream information for Source Server. The Source Server stream is named srcsrv. Finally, the build process uses the pdbstr.exe command-utility to add that stream information to write the relevant information. If you are ever curious about what that srcsrv stream actually contains, you can run this command-line utility:

C:\Builds\Calculator MAIN\Calculator MAIN_11.02.11.06\Debug\Obfuscated>pdbstr.exe –r -p:Calculator.pdb -s:srcsrv
SRCSRV: ini ------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Fri Feb 11 00:41:58 2011
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%( %var2%) /console >%srcsrvtrg%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=http://localhost:8080/tfs/DefaultCollection
SRCSRVTRG=%TFS_extract_target%
SRCSRVCMD=%TFS_extract_cmd%
SRCSRV: source files ---------------------------------------
C:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\Form1.cs*VSTFSSERVER*/Ca lculator/MAIN/Source/Calculator/Calculator/Form1.cs*32*Form1;C32.cs
C:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\Form1.Designer.cs*VSTFSS ERVER*/Calculator/MAIN/Source/Calculator/Calculator/Form1.Designer.cs*30*Form1.Designer;C30.cs
C:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\Program.cs*VSTFSSERVER*/ Calculator/MAIN/Source/Calculator/Calculator/Program.cs*30*Program;C30.cs
C:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\Properties\Settings.Designer.cs*VSTFSSERVER*/Calculator/MAIN/Source/Calculator/Calculator/Properties/Settings.Designer.cs*11*Settings.Designer;C11.cs
SRCSRV: end ------------------------------------------------

Publishing to Symbol Server

Publishing the symbols is the easier part of it. Essentially, the default build process template calls the symstore.exe add utility to publish the symbol files to the specified symbol server path. Additionally, there is some metadata added for the build information in TFS that will specify that symbols were published. This will be useful whenever the build retention policies kick in which we’ll cover further down.

Configuring Visual Studio to Use Symbol Server and Enabling Source Server Support

The next step is for each of the developers to configure Visual Studio 2010 to look for symbols if they aren’t found in the symbol server location for the company. You can get to it by going to Tools –> Options and then the Debugging –> Symbols options pages as shown below. Other debugging tools have similar options.

The next thing you will want to do is to enable source server support in Visual Studio. You can do that by going to the Debugging –> General options tab as shown below.

Now, just start using your debugging tool and in my case I have attached my Visual Studio Debugger to the process of my application that came from the build drop folder. Visual Studio gives me a small warning before it attempts to grab the source code from the TFS Version Control repository as shown below. You can see the exact command-line utility including arguments that is used by the debugger to retrieve the correct version of the file. Pure magic…

Update :  (2/14/2011) John Robbins has helped out by letting us know how we can disable this really annoying Source Server security dialog any time the debugger wants to get something from Source Server.  Thanks John!

Aside: If you notice, in my situation I have a particular problem. Since the TFS 2010 Build services are installed on the same machine as my application tier on my laptop, the default configuration for the build service to connect to TFS used http://localhost. That’s not going to be good whenever I have another developer start debugging using the assembly from my build server and the symbols. Their Visual Studio Debugger instance will try to hit localhost on their machine (where the source doesn’t exist).

For this reason, it’s important to make sure when you are configuring the build service to use the fully-qualified friendly DNS name for your application tier server. (Check out the blog post that’s linked to find out more information about this topic).

How Does Visual Studio Know Which Symbols Match for the Executable?

You have to always have symbol files that exactly match the assemblies you are debugging. How does Visual Studio know this though? There is actually a GUID that is embedded to both the assembly and the symbol file. You can find out what that GUID is by running the DUMPBIN command-line utility as shown below.

C:\Builds\Calculator MAIN\Calculator MAIN_11.02.11.06\Debug>dumpbin Calculator.exe /HEADERS

Microsoft (R) COFF/PE Dumper Version 10.00.31118.01
Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file Calculator.exe

Debug Directories

Time Type Size RVA Pointer
-------- ------ -------- -------- --------
4D54CC09 cv 69 00003864 1A64 Format: RSDS, {B7C62014-02BD-4F35-9718-104CE8CFB14C}, 1, c:\LocalBuilds\1\2\Sources\Source\Calculator\Calculator\obj\Debug\Calculator.pdb

You can see the GUID highlighted above. If you were to go check out the Symbol Server file share, you can also find the GUID used to differentiate between all of the different versions of the symbol files that are stored for a particular assembly.

Update :  (2/15/2011) I learned something new from Chris Schmich from the Visual Studio Diagnostics team.  He indicated that the PDB age (which is highlighted above in green) is also used to match the symbols.  You’ll notice that the PDB age for all of my symbols is 1 and is appended to the end of the GUID when stored in Symbol Server.  Thanks Chris for the extra information!

IntelliTrace Files and Symbol Server

I also wanted to mention that when testers use Microsoft Test Manager and run manual test cases where they have collected IntelliTrace logs, you’ll notice that when you open one of those IntelliTrace logs (for example attached to a bug work item) you will see the Symbol Server location that was collected from the assembly being tested as well:

This green-light should be awesome for you as a developer now because you can connect to the Symbol Server location and start debugging using the IntelliTrace log and the Source Server information contained inside of the symbols.

Retention Policies

One other thing to consider: as you have more and more builds performed using TFS 2010 Build, you’ll want to set up your retention policies. The Symbol Server file share can start to go up in size pretty quickly so you can have the retention policies also delete the corresponding symbols from Symbol Server if you choose by setting the “What to Delete” option.

You want to also make sure, however, that any “Released” builds should be marked as “Retain Indefinitely” to ensure that the retention policies never delete the symbols (or anything else about the build for that matter!)

Summary

There you go! Your developers will be very appreciative whenever all of this is setup. You’ll have a system that stores your symbols for whenever you need them and those symbols will have information to let the debugging utilities know where to grab the original source code from the TFS version control repository.

Ed Blankenship

By default, when you are setting up a new build definition in TFS 2010 that uses multiple Visual Studio solutions and projects, you end up with a drop folder with all of the compiled assemblies dropped in the root.  One notable exception to this is for web application projects where you will end up with a subfolder underneath the _PublishedWebsites folder for each of the web application projects.  You may not want everything to be in the root and instead want it organized.  There were several methods for how to do this using TFS 2005 or TFS 2008 but let me show you a way to do it for a TFS 2010 Build.

Create Workflow Parameter

Open up your build process template file and go to your “Arguments” tab (available in the lower-left hand corner of the workflow designer) to add a new workflow parameter.  My suggestion would be to use a new Boolean argument named “CustomizableOutputDirectory” as shown below.

Next, open up the Process Parameter Metadata Editor by clicking on the editor button for the Metadata workflow argument that is already defined.  Next, give your new process parameter some extra information so that someone editing the build definition will understand what this parameter is for.  You’ll notice that I’m also putting this parameter in the Advanced category since I don’t really need to create another category for only one new parameter.  Feel free to create a new grouping if you have more custom parameters in your build process template.

Once you finish these steps and check-in the file to version control, you’ll see your new parameter in the build definition editor as shown below.

Add Functionality to the Workflow

The next step is to add in the appropriate functionality for the customizable output directory.  What we will end up doing is adding an alternate path for when MSBuild is called to compile the Visual Studio solution or project each time.  I want to leave the default functionality though if the process parameter we created above is set to False.  So, the first step is to find the default functionality for compilation.  You can find it by navigating deep into the workflow and finding the “Compile the Project” sequence activity that contains the MSBuild activity that is used for compilation.  You can find it by navigating through these activities:

• Sequence
• Run on Agent (AgentScope)
• Type Compile, Test, and Associate Changesets and Work Items (TryCatch)
• Sequence
• Compile, Test, and Associate Changesets and Work Items (Parallel)
• Try Compile and Test (TryCatch)
• Compile and Test (Sequence)
• For Each Configuration in BuildSettings.PlatformConfigurations (ForEach<T>)
• Compile and Test for Configuration (Sequence)
• If BuildSettings.HasProjectsToBuild (If)
• For Each Project in BuildSettings.ProjectsToBuild (ForEach<T>)
• Try to Compile the Project (TryCatch)
• Compile the Project (Sequence)

The next step I would take is to drag and drop a new If activity and place the existing MSBuild activity in the Else container.  This allows for the default functionality to still continue if the value of the custom process parameter is False.  Set the Condition parameter for the If activity to the name of the custom process parameter that was defined earlier as shown below.

You will notice in the MSBuild activity that exists for default functionality, the CommandLineArguments workflow activity argument is set to the following.

String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments)

To implement our custom output directory functionality, we are essentially going to modify this one activity parameter to pass in a new value.  This will be the new expression that we will use for the MSBuild activity parameter:

String.Format("/p:SkipInvalidConfigurations=true;TeamBuildOutDir=""{0}"" {1}", outputDirectory, MSBuildArguments)

The easiest way to do this would be to copy the existing MSBuild activity and paste it in the Then container for our If activity.  You can then set the CommandLineArguments parameter for the copied activity to the new value that defines the new MSBuild parameter.

Extra Credit Aside:  Anyone know why we used outputDirectory instead of BinariesDirectory?

Opt-In for Visual Studio Projects

Once you have done all of the steps, you’ll notice that it didn’t actually change anything .  For each of the Visual Studio projects that you want to use the new functionality, you will need to “opt-in” by editing the .csproj or .vbproj Visual Studio project files and adding the new MSBuild property group shown below.

            
              
                
                  <!--
                
              
              
                
                   Customizable
Output Directory Opt-In for TFS Build (non-web application projects) 
                
              
            
            
              
                
                  -->
                  

                  <
                
                
                  PropertyGroup
                
                
                   
                
                
                  Condition
                
                
                  =
                "$(TeamBuildOutDir)
!= '' "
              
                
                  >
                  

                    <
                
                
                  OutputPath
                
                
                  >
                $(TeamBuildOutDir)\$(SolutionName)\$(MSBuildProjectName)</OutputPath
            
            
              
                
                  >
                  

                  </
                
                
                  PropertyGroup
                
              
              
                >
              
            
          

The change does break the _PublishedWebsites functionality for any web application projects though and you will need to use a different opt-in below for every web application project that is included in the build.

            
              
                
                  <!--
                
              
              
                
                   Customizable
Output Directory Opt-In for TFS Build (web application projects) 
                
              
            
            
              
                
                  -->
                  

                  <
                
                
                  PropertyGroup
                
                
                   
                
                
                  Condition
                
                
                  =
                "$(TeamBuildOutDir)
!= '' "
              
                
                  >
                  

                    <
                
                
                  OutDir
                
                
                  >
                $(TeamBuildOutDir)</OutDir
            
            
              
                
                  >
                  

                  </
                
                
                  PropertyGroup
                
              
              
                >
              
            
          

There you go… Check those project file changes into version control and you can now queue a new build and the outputs for each of the projects that are opting-in to this new functionality are created in subfolders in the drop folder.  It was also still continue to put web application projects into the _PublishedWebsites folders.

Ed Blankenship

For the longest time, opening a build process template (.xaml) file for TFS 2010 has been pretty painful.  It took a while for the workflow designer to eventually show up and the toolbox to be populated with the TFS Build Activities.  Nearly 30-45 seconds at times!

Recently, I applied a workaround that has dramatically reduced the time down to around 2 seconds!  Try it out:

1. Create a file called empty.xaml and place the following text in it:
   <Activity xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities">
   </Activity>
2. Open this file in Visual Studio.
3. In the toolbox panel, add a new tab called “Team Foundation Build Activities”.  Note that it is important to get the tab name correct because if it is not correct then the activities will be reloaded.
4. Inside the new tab, right click and select “Choose Items”
5. Click the Browse button
6. Load the file C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.TeamFoundation.Build.Workflow\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Build.Workflow.dll
7. Click OK to add the toolbox items to the tab.
8. Create another new tab called “Team Foundation LabManagement Activities”.
9. Inside the new tab, right click and select “Choose Items”
10. Click the Browse button
11. Load the file C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.TeamFoundation.Lab.Workflow.Activities\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Lab.Workflow.Activities.dll
12. Click OK to add the toolbox items to the tab.

Ed Blankenship

For quite a while, the Developer Division at Microsoft continued to use their internal build systems to build Visual Studio.  TFS Build had only been used by certain teams within the division but not standard across the division.  I had the opportunity to visit one of the huge build labs last time I was in Redmond and it’s impressive.  It was just one of them too.   I really got an appreciation for the complexity that was involved in building .NET, Visual Studio, and Team Foundation Server.   We’re talking huge builds that take up a lot of time.

Brian Harry just mentioned that they had hit a huge milestone for the division during their MQ phase and have gotten a build to run through the TFS 2010 Build system!  Sounds like they still have some work to go to get it tuned but getting a Visual Studio build through TFS Build is huge accomplishment!  Looks like they have even taken some of the experiences they gathered and already integrated improvements into the next version of the product.  That just benefits all of us as customers whenever Microsoft is eating their own dogfood. 

Congratulations!

Ed Blankenship

One of my favorite new build workflow activities is the FindingMatchingFiles activity.  It’s an activity that is provided out of the box for use during Team Build that returns an IEnumerable<string> of all of the files that match a particular wild card string.

It’s available in the toolbox under the Team Foundation Build Activities tab.  The full name of the activity is:  Microsoft.TeamFoundation.Build.Workflow.Activities.FindMatchingFiles.

Here is a typical usage if you are looking for all .CSS files in a particular folder.

The problem I was attempting to solve is how to find all of the files recursively in all of the subfolders as well.  All I had to do was change the match pattern argument to include a “**” in front of the original pattern and it worked like a charm!

Ed Blankenship

I mentioned in my last blog post about using TFS to manage TFS that I’d talk a little about how I use TFS 2010 to manage and deploy process template changes.  I’m excited to be able to provide some more details about it!

Background

I use to create batch files for deploying process template changes and store them in version control.  There’s certainly nothing wrong with that approach but I really wanted have an easier way to maintain this process that allowed reusability and even continuous integration.  Whenever I checked in a change to the process template branch for the test environment, I wanted it to immediately deploy those changes to that environment.  I also wanted to make it super easy for others to be able to make changes and then queue a deployment.

I need a build definition using TFS 2010 Build!

Build Process Template

So I have created a build process template that does exactly this.  My goals for this process template were to not require any custom workflow activities or custom assemblies to be required to get the build process template to work.  You simply only need to check-in the XAML file and begin using it.  That one requirement ended up being tougher to follow than I originally thought.  I had to take a few alternate methods that didn’t always end up with the best user experience but I think you’ll see that the template is still helpful.  (If you have ideas for improvements, please let me know!)

I hope you’ll see it as an example for creating “builds” that don’t necessarily compile & run tests.  Using Windows Workflow Foundation in Team Build 2010 makes it extremely useful for any type of process you want to automate.

Overview

At a high level, here is what this build process template attempts to accomplish:

• Standard Build Features:
  • Build Versioning
  • Label the source using the version number
  • Getting Latest Version or Specific Version
  • Associate Changesets & Work Items
  • Gated Check-In, Continuous Integration, etc.
• Ability to specify multiple team projects to update
• Ability to specify multiple work item types to update
• Backup each of the the work item type definitions that are currently being used in each team project (just in case!)
• Copy the version of the work item type definitions that are used and backups to a drop folder

Disclaimer:  I’m going to give this template the “works on my machine” label.  This template may not perform as advertised including blowing up your server, deleting everything on your hard drive, or cause your hair to fall out.  Use at your own risk!  You have been warned.  If it works for you, awesome!  If not, please let me know about any issues or areas of improvement.

How to Use the Build Process Template

After you downloaded the template and check the XAML file into your build process templates folder, you’ll want to create a new build definition to use it.  Make sure you have also checked in your process template to a version control folder.

Workspace Definition

Specify the version control folder that contains your process template.  By default it will download the entire team project and scoping down the build process template allows your build to run quicker since it is not downloading everything in the team project.

Process Tab

Choose the new build process template file from the available process templates:

Note:  If you don’t see the build process template as an available item in the combo box, you’ll want to click New and then choose the XAML file you checked in as the existing build process template.

The next thing you’ll want to do is specify the team projects you want to update and the URL for your TFS 2010 team project collection.

The last two required process parameters are extremely important.  You need to specify the work item type names and the server path locations to the work item type definition (XML) files.  Each of the process parameters are string lists so you’ll want to make sure you match them up in the exact order in both lists.

Work Item Type Names (for MSF Agile)

Work Item Type Definition Files

Make sure you specify the server path location for each of the WITD files!  I ended up reusing a dialog for this purpose that you may have been used to seeing in other builds you have configured.  It’s the same editor that allows you to choose solution and project files to build.  We can use it for this purpose too!  Just be sure to select the “All files (*.*)” filter for the Items of Type combo-box.

Again – make sure you put each of the XML files in the same order that you used for the work item type names.  For example, your Bug.xml file will be the first in the collection and UserStory.xml will be the last if we are using the same WITs as the figure above.

Other Details

Make sure that your build agents have Visual Studio Team Explorer 2010 installed so that witadmin.exe will be located.  You can always use the new build agent tagging functionality to identify which agents have Team Explorer available and then use the Agent Settings process parameters to limit the build to only reserve agents with the tags you specify.

Finally, make sure your build service account has the appropriate permissions to be able to import new work item type definitions to your team projects.

[Updated – 3/24/2011]

Thanks for reporting feedback and bugs!  Latest version includes the following bug fixes and improvements:

• 10/26/2010:  Will properly associate work items and changesets correctly now.
• 10/26/2010:  Discovers location of witadmin.exe on build servers with a 32-bit OS installed.
• 10/26/2010:  Detects error on import and writes as build error instead of message.  Allows for the build to not succeed in this circumstance.
• 3/24/2011:  Reduced the verbosity of some of the build workflow activities.  This should reduce the noise in the build log and show what is most important.  Be sure to set the entire build’s verbosity higher if you need to troubleshoot issues.  (If you are interested in how to lower a particular workflow activity’s tracking verbosity, check out page 402 in our new TFS 2010 book).

Download the Build Process Template

Let me know if you have any feedback about things you like or areas for improvement!  Feel free to comment below so I don’t lose track of the suggestions.

Ed Blankenship

I’ve been hitting my head against the table today trying to have a nice experience for editing a collection of string values as a custom build process parameter in my TFS 2010 build definition.  The problem comes with what editor is actually used to edit the process parameter at design time.  You can specify a custom editor for any of your custom build process parameters which is really handy but I needed the ability to use editors that were out of the box but still provided a sufficient experience to the end user.

My journey towards a solution…

Attempt 1

I began really wanting to have one build process parameter that had the type of Dictionary<string, string>.  That didn’t work out so well because when I went to edit it in my build definition, I received this editor and the add/remove members buttons.

Attempt 2

I gave up on the Dictionary<T, T> approach and decided that I could handle it by specifying two collections of type Collection<string>.  I also attempted to try List<string> and even a String[] but ended up with this editor that seemed to not like System.String.

Attempt 3

I found Microsoft.TeamFoundation.Build.Workflow.Activities.StringList.  It is a custom type that is known to Team Build 2010 and even has a custom editor that is registered to it that shows up.  That editor is Microsoft.TeamFoundation.Build.Controls.WpfStringListEditor.  Works great for me!  Take a look:

Ed Blankenship

Looks like this past weekend Don from Microsoft Learning announced the public availability of the Team Foundation Server 2010 Microsoft certification exam.  I had several people ask about what happened to the Beta exam for 70-512 and the only thing I can see is that it was released directly to the public without a Beta phase.

If you pass this exam, you will receive the Microsoft Certified Technical Specialist certification for TFS 2010.  Officially it will indicate:
MCTS: Visual Studio 2010 Team Foundation Server, Administration

I’ll be taking the exam this weekend so I’ll let everyone know how it goes.  Well… as much as I can!  Exam candidates agree not to disclose details about the exam when they take it.

There aren’t any preparation materials available just yet as listed on the Exam Details site.  It does however list the topics that are covered on the exam:

About this Exam

This exam is designed to test the candidate's knowledge and skills on installing, configuring and maintaining Visual Studio 2010 Team Foundation Server.

Audience Profile

This exam is intended for candidates who install, configure, and manage a Microsoft Visual Studio Team Foundation Server (TFS) 2010 implementation. Candidates typically work in an enterprise development organization that provides process automation services by using TFS.

The qualified candidate has:

• a solid understanding of the TFS architecture and components.
• experience installing and configuring a TFS in both single-server and multi-server configurations.
• experience managing security for TFS components.
• experience configuring and using Team Build.
• experience adapting process templates to an organization.
• experience managing project artifacts with TFS version control.
• experience configuring and using work item tracking.

Skills Being Measured

This exam measures your ability to accomplish the technical tasks listed below.The percentages indicate the relative weight of each major topic area on the exam.

Installing and Configuring TFS (27%)

• Install TFS.

  This objective may include but is not limited to: SQL Server version support, installing TFS in a multi-tier or multi-machine environment, installing TFS in a load-balanced environment, setting up version control proxy

• Configure application tier

  This objective may include but is not limited to: validating an installation, configuring SMTP for TFS, changing the URL (friendly name), changing the default SharePoint Web application, setting up reporting (SQL Server Analysis Services)

• Migrate and upgrade TFS.

  This objective may include but is not limited to: upgrading TFS 2005 or TFS 2008 to TFS 2010, importing a source base from Microsoft Visual Source Safe (VSS), a third-party revision control system, or a sub-version

• Install and configure team lab.

  This objective may include but is not limited to: set up environment templates, installing and configuring test agents, installing and configuring Virtual Machine Manager (basic Virtual Machine Manager installation), creating library shares or resource pools

• Install and configure multiple build agents and controllers.

  This objective may include but is not limited to: tagging, binding a controller to a project collection, adding as build agent

Managing TFS (27%)

• Manage Team Project Collections.

  This objective may include but is not limited to: moving project collections, managing team collections and projects, creating and configuring team project collections, moving team projects from one collection to another, creating a team project with SharePoint and SQL Server Reporting Services, cloning (splitting team project collections, partitioning)

• Configure for backup and recovery. 

  This objective may include but is not limited to: backup and recovery of TFS and related components, recover a failed application tier, recover a failed database tier, implement a disaster recovery plan

• Monitor server health and performance.

  This objective may include but is not limited to: application tier logs, monitoring the server for performance issues (monitoring activity logging database and TFS server manager), monitoring job infrastructure for failed jobs (monitoring warehouse adapters and warehouse jobs), cleanup of stale workspaces and shelvesets, cleanup builds (applying retention policies), setting up team build to use a version control proxy server

• Administer TFS application tier.

  This objective may include but is not limited to: retiring or archiving projects and purging the system, rebuilding a warehouse, configuring user permissions by using Active Directory Domain Services  and TFS groups, moving a TFS instance to a new server or a new domain, configuring security for TFS Work Item Only View

• Manage reporting for TFS.

  This objective may include but is not limited to: basic reporting using Microsoft Office Excel Services, adding a custom report to a SharePoint project portal, uploading a new SQL Server Reporting Services TFS report, configuring to enable a report to appear in a SharePoint project portal

• Set up automated functional and UI tests.

  This objective may include but is not limited to: setting up a build definition, configuring the build definition to use the proper lab environment, setting up tests to work on an installed agent, setting up a service as interactive, setting up data collectors

Customizing TFS for Team Use (24%)

• Configure a team build definition.

  This objective may include but is not limited to: setting up for a Symbol Server and Source Server, setting up for test impact analysis, setting up for custom build numbers, configuring build log verbosity, setting up for code analysis, setting up for automated unit testing, setting up for architecture validation

• Configure and execute a build. 

  This objective may include but is not limited to: queuing a build with parameters, reconciling workspaces as part of a gated check-in workflow, setting up build triggers (gated check-in, continuous integration, scheduled build)

• Modify a process template.

  This objective may include but is not limited to: customizing a process template by changing the workflow for a work item, adding a new work item type as a child of an existing work item (WI), uploading and downloading process templates

• Configure a team project.

  This objective may include but is not limited to: areas and iterations, default security groups, portal settings (team project portal site URL, process guidance URL)

• Apply work item customizations.

  This objective may include but is not limited to: link types, Global list, creating a new WI category and adding existing WI types to the new category, adding or removing fields, transitions, queries, customizing a workflow, creating or editing a work item type, importing and exporting work item types, renaming work item types

• Create Work Item Query Language (WIQL) queries.

  This objective may include but is not limited to: query folders and permissions, query types (tree, flat, directed), defining WIQL keywords, adding fields to a query, creating a WIQL query by using Team Explorer, identify built-in macros

• Configure client connectivity to TFS.

  This objective may include but is not limited to: configuring Visual Studio, Team Explorer, Microsoft Excel, Microsoft Project, and other tools to connect to TFS, configuring clients for proxy server

Administering Version Control (23%)

• Create and manage workspaces.

  This objective may include but is not limited to: cloaking, undo delete, modifying a workspace, deleting a workspace, specifying the workspace visibility, restoring deleted items, unlocking other users’ checkouts, pending changes, and code

• Configure shelvesets. 

  This objective may include but is not limited to: private builds, creating a shelveset, deleting a shelveset, opening another user’s shelveset

• Branch and merge source artifacts.

  This objective may include but is not limited to: track change visualizations, converting a folder into a proper branch and creating a new branch, merging and resolving file conflicts, viewing branch hierarchy, creating a branch, deleting a branch

• Configure version control proxy.

  This objective may include but is not limited to: cache hit ratio, setting up the cache size, setting up for multiple TFS servers

• Configure team project version control settings.

  This objective may include but is not limited to: enable multiple checkout, enable get latest on checkout, configuring check-in policies for a team project (work items, builds, code analysis, testing policies)

Good luck!  Let me know how you end up doing on the exam.

Ed Blankenship

During the first week of April, a little package was sitting on my front porch with the first book to be released on the Visual Studio 2010 release that deals with the new Application Lifecycle Management (ALM) features.  For those of you who don’t know, this essentially means the former “Team System” line of products as we were exposed to it in the 2005 and 2008 releases.  Although the entire Visual Studio suite of products is considered something that helps you with ALM, the book primarily focused on Visual Studio 2010 Ultimate, Visual Studio 2010 Premium, Visual Studio 2010 Test Professional, Visual Studio 2010 Lab Management, and Team Foundation Server 2010.  During the Introduction, I even appreciated how the authors discussed about “where Team System went.”  It’s the best explanation of the branding change that I’ve seen to date.

I was extremely excited to start immediately reading the book.  Even though I have been closely involved with the 2010 release as a Microsoft MVP, when I started to read this book my goal was to be exposed deeper in the feature set being introduced in the 2010 release.

At the time of writing this blog post, the book was selling for $34.64 at Amazon.  The suggested retail price is $54.99.  It is currently #7 in the Software Development books category!

Strengths

If you are new to the ALM features in Visual Studio, I felt this book really offered you the ability to get the high-level overview of all of those features.  It’s essentially similar to a “survey” course that you would have taken in college.   It’s 696 pages that ends up going through all of the Visual Studio client and server features at just the right level of detail. There were even some areas that I felt that I learned more about and hadn’t been exposed to heavily in the past.

The architecture features were something that I had hoped to learn the most from.  They have just never been something that I dived into great detail during the 2010 release cycle.   All of the new UML diagrams that are available including the new architecture features like Use Case, Activity, Sequence, Component, Class, Dependency, and Layer Diagrams.  There was a also a great introduction to the Architecture Explorer.

The testing features have really been what has made up a majority of the Visual Studio 2010 release and the book definitely reflects that.  Going through the testing features, I really felt like I understood the end to end story.  It felt very rounded out!  These chapters are where I picked up a majority of the nuggets of information.  I can’t tell you how many times I said “wow, I didn’t know you could do that.”  I also feel like this is a great place to pick up some introductory knowledge about how Visual Studio Team Lab Management fits into the ALM story.  I also kept thinking how great this book would be for the testers on your team that are new to the Microsoft testing platform and Team Foundation Server.

There are so many changes to TFS, I can’t even begin to start describing them.  Thankfully, the book did a great job.  Especially with the revamp of Team Build to use Windows Workflow Foundation.  You can even download the Team Build chapter from the book for free here:  Team Foundation Build.  Other than automated builds, you’ll get a good pass by all of the rest of the new TFS 2010 features and architecture/topology changes.

There was a whole chapter dedicated to debugging with IntelliTrace!  That’s awesome.  I’m very much a fan of IntelliTrace and think that will truly change the way you develop.

Criticisms

I have been hoping to have a book available out there that really only discusses TFS.  The book definitely has a few chapters available on TFS and spends a good amount of time but that discussion is not the nitty gritty that I think some readers out there are really looking for.  With that said, I don’t think this book was positioned for the “TFS Administrator” exclusively.  Again, I really think this is a survey-level review of the entire ALM stack of features for Visual Studio.  That doesn’t allow you to go into the depths of any particular product.  There currently isn’t a book available for TFS 2010 with the level of detail that I am sure some readers out there are hoping for.  We’ll see what happens in the months to come…

My next criticism isn’t so much for the content of the book as what is media choices are available.  I own a Kindle DX and I imagine a few other techies in the world have some type of eBook reader as well.  I was hoping to have a CD that contained a DRM-free PDF that I could copy over to my Kindle DX whenever I’m traveling and need a quick resource for reference.  Wrox certainly does allow you to get a PDF of books but you have to order them separately even if you had purchased the hard copy.

Finally, the only other thing that I noticed was in that chapter about IntelliTrace (see above) there wasn’t a mention of Symbol & Source Server.  I couldn’t believe it.  There is definitely a discussion later in the book about Team Build’s integration with Symbol & Source server but I was hoping to have seen some more detail in the IntelliTrace chapter about the importance of having them setup for your organization.  You’ll want to put two and two together.

Now that I’m finished scrounging from the bottom of the barrel to find some criticisms… :)

My Recommendation

Hands down, get this book.  I think it’s well worth it.   I know each of the authors and it really looks like they put a tremendous amount of effort into writing the book.  The topics are really presented well and at the right level of detail for someone really wanting a crash course in all of the Visual Studio ALM features.  I can’t even tell you how many new nuggets of information that I ran across of things that I didn’t even realize were in the product.

It certainly gets my stamp of approval! :)  Kudos to the authors.

Very respectfully,

Ed Blankenship

Microsoft MVP of the Year, Visual Studio ALM and Team Foundation Server

Not sure if you have seen this but some of the product managers on the TFS Build team at Microsoft have been putting together some great blog posts for how to create custom build activities and get a little background about Windows Workflow 4.0 and how it relates to TFS Build 2010.

• How to Create a Custom Workflow Activity for TFS Build 2010 by Jim Lamb
• Windows Workflow 4.0 – CopyDirectory (Part 1 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyDirectory (Part 2 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyDirectory (Part 3 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyFile by Patrick Carnahan
• Writing Custom Activities for TFS Build 2010 (Beta 1) by Aaron Hallberg
• Display Custom Build Information by Jason Prickett
• Modifying the Default Display of Build Information by Jason Prickett

Also, we’ve been trying to put together a CodePlex project that’s designed to be a central location for contributions of Team Build 2010 customizations like custom activities, build process template customizations, build tools, etc.  You can take a look here:  http://teambuild2010contrib.codeplex.com/.  I’d encourage you to think about contributing any of your customizations to this project.  I know I’m personally hoping that it will be the “go-to” place for some of the common build activities that people need.  If you happen to have any feature requests for build activities, feel free to request one in the discussions and we’ll add it to the backlog:  http://teambuild2010contrib.codeplex.com/Thread/List.aspx

Thanks!

Ed Blankenship

In Team Foundation Server 2010, you know have the ability to (easily) have multiple build agents on the same build server.  You were able to do this in TFS 2008 but it really wasn’t supported.  However, this raises an interesting challenge:  some processes and executables aren’t designed to handle being run simultaneously in multiple contexts on the same build machine.  Some applications can’t or have a difficult time handling concurrent access from multiple build servers at the same time as well.

I’ve listed a few of the scenarios that I can I remember off the top of my head:

• Automated UI Testing – running automated UI tests from two different builds on the same build machine can lead into utter confusion!  :)  Mouse clicks going everywhere!  Let’s just stick to one set of automated UI tests running on an individual machine at the same time.
• Running Automated Tests that Collect Code Coverage Information -  This was an interesting limitation that I found in the 2008 release.  It seems that the code coverage data collector did not support collecting from more than one automated testing run happening concurrently on the same machine.  (This might actually have been addressed in the 2010 release but I’m not quite sure.)
• Dotfuscator – As far as I remember, this was another tool I remember having concurrency issues on the same build machine.
• Symbol Server Store Access – This is something new to me and I’m not intimately familiar with all of the details behind this limitation.  It looks like you can not use the symbol server publishing tools against the same symbol server storage location at the same time even on multiple machines.  (See example below.)
• Other Tools – I’m sure there are other build processes and tools we use that have limitations.  I’m sure many will be found out now that concurrent usage is more easily possible now.  Leave a comment below if you find any other examples and I’ll add them to this list.

Thankfully, the Team Build folks have provided us the ability to handle those specific scenarios where concurrent access isn’t supported as part of the build process.  That’s through the use of the Shared Resource Scope activity.  (Microsoft.TeamFoundation.Build.Workflow.Activities.SharedResourceScope)

Basically what it does is define a region of the build process that will only be allowed to be entered by one build across the entire Team Project Collection (even multiple build machines/agents) that share a matching resource name string.  It’s very similar to how we use the lock statement in C# or creating mutex objects.  (You might have to dust off those old computer science books from school.)

However, if you only want to limit the scope to a particular build server (instead of the entire Team Project Collection) then you can just put the build server machine name into the resource name string.  Don’t hardcode the machine name though and instead use one of the properties that are provided for you (in case the build doesn’t run on the same build machine every run because of the new agent pooling feature.)  Instead you could use an approach like this for the resource name expression:

          =String.Format(“{0}_{1}”,
BuildAgent.BuildServer, “AutomatedUITesting”)
        

Example in the Default Build Process Template in TFS 2010

Interestingly, there is an example usage of this activity and pattern available for us to look at in the default build process template file that’s available out of the box.  It’s usually located in version control here:  $/TeamProjectName/BuildProcessTemplates/DefaultTemplate.xaml.  Lower down in the default process, there is a section that attempt to publish the symbols to a symbol server storage location if you have specified it in your build definition properties.  My Assumption:  However, since only one build server can be publishing to a particular location at the same time, then a controlled scoped region is created based on the location property. (SourceAndSymbolServerSettings.SymbolStorePath)

That way you don’t have to worry about any build agent inside a Team Project Collection ever publishing to the same symbol server location at the same time.

Recently added:  It looks like this particular issue has already been discussed and that my assumption above is correct.  Adam blogs about it here.  Check it out.  How about that?

One more thing to note about symbol server publishing is the use of the SharedResourceScope activity in the build process template. The purpose is to make sure that concurrent instances of symstore.exe aren’t adding symbols at the same time, as the tool doesn’t support concurrent access to a symbol server share. SharedResourceScope uses the Team Foundation Server to control access to an arbitrarily named resource, in this case the share. That way, if multiple builds are trying to publish symbols at the same time, the requests are queued and only one will publish at a time, while the others wait (instead of fail due to file access errors or “step on each others’ toes”). PublishSymbols does not care about shared resource locks, but it is contained within the SharedResourceScope, so won’t be executed until the lock is appropriately acquired.

Other Properties Available for SharedResourceScope Activity

As you can see above there are a few other properties available for you to configure for this activity:

• MaxExecutionTime:  This is a TimeSpan that can be specified to limit the amount of time that a particular agent has control of the scope.  This is particularly useful for a resource scope that is going to be heavily used and can help you prevent a rogue build from eating up that resource indefinitely.  If the process inside the scope can’t complete before this time period has expired then an exception gets thrown.
• MaxWaitTime:  This is a TimeSpan that can be specified to limit the amount of time to wait for control of the scope.  The example above limits the amount of waiting to one hour and if it doesn’t reserve the scope within that time period an exception gets thrown.

Thanks to Aaron Hallberg for all of the background information and existence of this activity!

Ed Blankenship

Disclaimer:  I’m writing this at a time when only Beta 1 is available for Visual Studio Team System 2010 so the information may have changed by the time it has been released.  I have included links to the relevant MSDN articles which should remain valid after release time so just double-check.

This small little additional feature is actually one that I have been looking forward to for a long time.  In Visual Studio Team System and Team Foundation Server 2010, you will now be able to limit your test runs to specific test categories with a new command-line option on MSTest.exe and therefore in Team Build 2010 which calls MSTest.exe automatically for you.

Back in the day… You would need to create test lists (.VSMDI files) in VSTS 2005 and VSTS 2008 to basically “categorize” your automated unit tests by putting them into different lists.  One handy thing about them is that the lists could be hierarchical which helps out at build time.  When you wanted to run a specific subset of tests either locally using MSTest.exe or in Team Build, you would just specify the .VSMDI file to use and then the test list you wanted to run.  Not too bad, but it’s a pain to keep up with those test lists.  Serious pain.  However, the thing that I hated absolutely most about them is that you could only edit the .VSDMI files if you purchased Visual Studio Team Suite or the Tester Edition.  So that means that if you have just the VSTS Developer Edition then you are pretty much out of luck.  For most places that I have seen, it’s usually the developers maintaining those test list files not the testers.

For this reason I actually prefer and will be recommending the Test Container and Category approach going forward in 2010.  Test Containers are essentially files that contain tests in them.  For example, unit tests (and other compiled tests) are stored in .dll files and ordered tests are in .orderedtest files.  I like this approach.  In automated builds I just want to specify which files contain the tests that I want to run and then if I want to limit the test run to just a subset I can just list which categories to run. 

A great example of this is what I call the “BVT” category.  These are the tests that you have identified to be your “smoke” tests that make sure a build is okay.  If these tests fail then you’ve probably got a bad build.  (BVT = Build Verification Tests) So I would limit the test runs on any CI or even the new Gated Check-In builds to just those BVT tests.  Quick & dirty verification is really all you need for those builds leaving a more extensive automated test pass to happen during the nightly or weekly build.  If you’re not familiar with the new Gated Check-In feature in TFS 2010, check out Brian’s blog post or Patrick’s blog postfor more information.  It’s a killer feature.

This does rely on one thing though… each “developer” of an automated test needs to make sure they add the correct attribute(s) to their test methods.  You don’t have to keep up with maintaining the .VSDMI files any longer but you do have to make sure you mark each method appropriately.

You can even use test categories with the new types of automated tests available in 2010 like Coded UI Tests.  It doesn’t just have to be unit tests.

How to Specify a Category in an Automated Test

This part is pretty easy.  You just add as many TestCategory attributes to the test method as you need.  Here’s an example in C# using multiple test categories for a test method called DebitTest:

[TestCategory("Nightly"), TestCategory("Weekly"), TestCategory("Monthly"), TestMethod()] public
void DebitTest() { }

Alternately, you can select a test in the Test View tool window and then set the category by using the Properties tool window in Visual Studio and it will add the appropriate attributes to the methods for you.

How to Specify which Categories to Run in an Automated Build with Team Build 2010

Okay… this part is easy too. :)  Build definitions now have build properties that can be exposed to the end user in the Build Definition Details dialog or in the Queue Build dialog.  This is handy because you could by default not set a filter to run under normal circumstances (triggered or default manual builds) or you can change it when manually queuing a build if you want that build to run differently.  Either way it’s the same for setting the categories.  If you’re using the default build process workflow that is available out of the box, then just scroll down through the property list until you reach the Testing section which includes a build property called Test Category.  Leave it blank if you want to run all tests or specify the categories you’d like to limit it too:

According to the MSDN documentation for the Test Category switch, you can combine multiple categories in different combinations instead of just specifying one category.  Very handy – here’s some examples:

/category:group1 runs tests in the test category "group1".

/category:"group1&group2" runs tests that are in both test categories "group1" and "group2." Tests that are only in one of the specified test categories will not be run.

/category:"group1|group2" runs tests that are in test category "group1" or "group2". Tests that are in both test categories will also be run.

/category:"group1&!group2" runs tests from the test category "group1" that are not in the test category "group2." A test that is in both test category "group1" and "group2" will not be run.

What I’m not sure about is whether you can specify test categories when using the old Upgrade Build Workflow template .xaml file… I’ll check on that and then update the blog post.

It’s worth noting that if you are going to use the test category method to limit test runs, you must use test containers.

Limiting Test Runs Based on Test Priorities

If you noticed in the screenshot above from Team Build, you can also limit your test run to tests that are in a specific priority range.  How do you specify the range for your test methods?  You can use the Properties window when selecting a test in the Test View tool window or you can add the Priority attribute manually to the test method.  After that you just specify the range of priorities to use in the test run.

[TestCategory("Nightly"), TestCategory("Weekly"), TestCategory("Monthly")]
[TestMethod()] [Priority(1)] public
void DebitTest() { }

Additional Note:  It appears that the product team is actually encouraging people to move away from the old .VSDMI approach in favor of categories.  Check their note out:

Note

Test categories are recommended for use over the test lists functionality from earlier versions of Microsoft Visual Studio Team System Test, unless you have to create a check-in policy which requires a test list. For more information about check-in policies, see How to: Add Check-In Policies.

Take care and happy testing,

Ed Blankenship

Just wanted to take a few seconds to post the slide deck I’m using for my Real World TFS sessions.  I’ll post a link to the recording of the MVP TV session earlier today when it’s made available!

Ed Blankenship

Also really excited about doing my first ever MVP TV set up by the Microsoft MVP program.  Hope to see you there!  We have an extra thirty minutes at the end so be sure to bring your questions.

MVP TV: Real World TFS: Tips for a Successful Team System Implementation

Wednesday, July 15^th, 2009 | 9:00am – 10:30am (PDT, Redmond time) or 12:00pm – 1:30pm (EDT, New York City time)

Targeted: This Product Group Interaction is open to  all Developer MVPs in all Technical Expertise and  public audience.

So you’ve decided that Visual Studio Team System & Team Foundation Server is going to bring your organization added value (because it will :)) but what do you do now?  Please join Ed Blankenship as he covers the 2.5 years of successful implementation of VSTS and the experience of that journey at Infragistics, the world’s leading maker of software development tools.  The session intends to cover each phase of the implementation of all affected areas for a smooth adoption:  Version Control, Builds, Work Item Tracking, global deployment, moving multiple teams, training, automated testing, migration from legacy systems, and integration with other systems and TFS.  The goal will be to go through at a high-level of what it takes to make you successful by learning from the challenges and obstacles overcome.  We’ll also look in the future with VSTS 2010 and see how strategic planning will help make a successful adoption of the new features in the upcoming 2010 release.  The session is led by a Microsoft MVP (Team System) & Champ who has been in the trenches during the whole implementation.

Prerequisites:  A healthy attitude in learning from other peoples challenges and a strong desire to make real change within your organization!

About Ed Blankenship: Ed is a Microsoft MVP, Microsoft Certified Application Developer, and works as the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components. His expertise consists of Microsoft Visual Studio Team System and Team Foundation Server. He is also a technical evangelist for Rich Client applications (primarily Windows Forms & Windows Presentation Foundation.) He has been a technical editor for several Silverlight books, an article author, and has spoken at various user groups, events, and conferences.

PJ Forgione has invited you to attend an online meeting using Live Meeting.
Join the meeting. (Link: https://www.livemeeting.com/cc/mvp/join?id=NP5FQZ&role=attend&pw=A49410Y0D )
Audio Information
Computer Audio
To use computer audio, you need speakers and microphone, or a headset.
Telephone conferencing
Use the information below to connect:
Toll-free: +1 (866) 500-6738
Toll: +1 (203) 480-8000
Participant code: 5460396

Ed Blankenship

While I’m up in New Jersey working at the Infragistics headquarters office, I’m going to have the privilege of speaking at the New York City VSTS User Group on July 28, 2009 at 6:30 PM.  Come see me if you’re in the area!  Because of security concerns at the building, you do need to register ahead of time if you’re planning to attend.

Real World TFS: Tips for a Successful Team System Implementation

Description:
So you've decided that Visual Studio Team System & Team Foundation Server is going to bring your organization added value (because it will :)) but what do you do now? Please join Ed Blankenship as he covers the 2.5 years of successful implementation of VSTS and the experience of that journey at Infragistics, the world's leading maker of software development tools. The session intends to cover each phase of the implementation of all affected areas for a smooth adoption: Version Control, Builds, Work Item Tracking, global deployment, moving multiple teams, training, automated testing, migration from legacy systems, and integration with other systems and TFS. The goal will be to go through at a high-level of what it takes to make you successful by learning from the challenges and obstacles overcome. We'll also look in the future with VSTS 2010 and see how strategic planning will help make a successful adoption of the new features in the upcoming 2010 release. The session is led by a Microsoft MVP (Team System) & Champ who has been in the trenches during the whole implementation.

Presenter: Ed Blankenship

Bio:
Ed is a Microsoft MVP, Microsoft Certified Application Developer, and works as the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components. His expertise includes Microsoft Visual Studio Team System and Team Foundation Server. He is also a technical evangelist for Rich Client applications (primarily Windows Forms & Windows Presentation Foundation.) He has been a technical editor for several Silverlight books, an article author, and has spoken at various user groups, events, radio shows, and conferences.

Date/Time:  07-28-2009 6:30 - 8:00 PM

Location: Microsoft Offices in NYC at 1290 Avenue of Americas, 6th Floor

Click here to Register

Ed Blankenship

I’m up really early this morning.  I’m about to head to the airport to spend my Independence Day weekend in the Carolinas for some much needed beach vacation and visit with friends.  Thankfully, I didn’t miss Martin Woodward letting me know that the latest Radio TFS episode was made available just a few moments ago that includes my interview about our use of TFS and Visual Studio Team System at Infragistics.  It’s a longer episode than normal so it’s perfect if you’re going to be spending some time at the beach like me and listen to a fun talk.  We both really enjoyed chatting for this episode so we hope you enjoy it as well!

Using TFS with Ed Blankenship

In this episode we sit down and chat with Ed Blankenship about the use of Team Foundation Server at Infragistics. Ed has had some interesting challenges and experiences in running their TFS instance.  Additionally they have done some fairly advanced integration work which we discuss in detail.  This is a double-length show, so hopefully plenty of stuff to enjoy if you are sunning yourself on a beach somewhere.

Ed is the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components.  He is also a Microsoft MVP in Visual Studio Team System.

     Play Now: Using TFS with Ed Blankenship

As the Release Engineering Manager, he leads the Release Engineering Department which is responsible for automated builds, creating product installers, packaging source code for customers, source configuration management/version control, metrics, release management, work item tracking, licensing enforcement, and development of internal productivity tools.  The department also is responsible for TFS Operations & Maintenance.

Ed has been a technical editor for the Wrox Silverlight 1.0, Silverlight 2 Developer's Guide, and Silverlight 2 Bible books, author of numerous articles, and has spoken at various user groups, events, and conferences.

Links from the show:

• Ed's Blog
• Microsoft Process Template
• Martin's Blog Post on Check-in Policies
• How to turn on Activity Logging with TFS 2005

As usual send any feedback to radiotfs@gmail.com.

Feel free to let me know if you have any questions based on the Radio TFS chat.  I’m more than happy to get them answered for you!

Take care,

Ed B.