The ALM Rangers heavily leverage the power of Team Foundation Service (TFService) for all of our projects. While TFSService doesn’t contain all of the features found in on-premises Team Foundation Server, for most projects and applications that we build, the features available within TFService are sufficient. For this project we are working on the V2 of the ALM Readiness Treasure Map, a Windows 8 Store App. If you are not familiar with V1, read the article, A Treasure Hunt Through ALM Readiness, in the MSDN magazine and download the app from the Windows 8 Store. With this project, there are two features that we can’t accomplish with TFSService. TFService does not include symbol server support. In addition Windows 8 Store apps cannot be built with Team Foundation Service. If we were to use an on-premises build server with Team Foundation Service, we could support building the application. Read the Building and Validating Windows Store Apps with Team Foundation Service article in the April 2013 edition of MSDN Magazine for a great walkthrough on creating an on-premises build server for TFService to build Windows 8 Store apps.
Since we are using a pure TFService solution, we will need to store the symbols, binaries, and the app package in source control for released and internal builds. Below is the solution enabling and using the debug symbols and also storing binaries and packages for release and internal builds. This is our initial plan and it may evolve as the project progresses. In addition, hopefully in the future TFService will support both of these features. Be heard and vote for Windows 8 Build Support and Symbol Support on Visual Studio User Voice. As always, we always appreciate your feedback and your ideas for this solution.
Enabling and Using Debug Symbols
Enable full debug symbol information for the release build configuration in addition to the debug build configuration. This will allow us to have detailed stack information about the error that include line numbers of the errors and debug the application without the source control.
Also ensure that the include public symbols, if any, to enable crash analysis for the app option is checked when creating the app package.
To be able to use the debug symbols within the application, perform the following steps. The TreasureMap application’s namespace begins with Microsoft, so you need to remove the Microsoft.* exclusion from the options.
Once the symbols have been included, if you wish to debug the issue from production, use Visual Studio to debug the application by choosing Debug Installed App Package… option.
Choose the installed app package to debug
From within Visual Studio, you will be able to hit exceptions and step through the application’s code.
Storing Release Builds
When a release candidate version has been accepted by the Windows app store, take the output from the packaging and binaries and put it into the following folder structure. Then check-in all of the files into source control as shown below:
Storing Internal Builds
Internal Only releases should be built locally and stored in the Drop folder in TFService. Use the following folder structure and naming convention. Under varTreasureMap_Dev, create a new folder using the format [Date].[Build Number]. In this folder, copy and check in the binaries / output from the build into the Binaries folder. Also create the app package files locally by choosing Project > Store > Create App Packages. Be sure to choose No when asked if you want to publish to the Windows Store. After going through the wizard, copy the output to the PackagedOutput folder under the build folder and check in these files. Send an email to the team letting them know a new internal version is available for side loading to test.