Building Windows 8 Modern (Metro) Applications with Team Build 2010

It's been a while since I have had the chance to post, but just got this up and running.

How to get Team Build 2010 to build and Package Windows 8 Modern (Metro) Applications:

1. Install Windows Server 2012, just hit MSDN (http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx)
2. Install and configure Team Build 2010 (with SP1 of cource).
3. Install Visual Studio 2012 on the machine.
4. Done! (Oh and this works for other Visual Studio 2012 projects)

When you look at the build drop location, under the individual published Application folder you will see an AppPackages:

• AppXUpload  = Combined archive of your application for publishing to the AppStore
• Folder with the {name of the Application}_{Version Number}_{Platform}_Test
• To side load it, run the Add-AppDevPackage on your target machine
• Make sure to have Powershell scripting set so you can execute (I cheated and used Unrestricted)  http://technet.microsoft.com/en-us/library/ee176961.aspx
• If not already on that machine, you will be prompted for a Windows 8 Developer License (http://msdn.microsoft.com/en-us/library/windows/apps/hh974578.aspx)

TFS 2010 SP1 Goody: Using the API to retrieve Code Coverage Information for a Build

There was a new approach for exposing Test related information in TFS 2010 in the API thru the new TestManagementService.  It was particularly easy to get the Unit Test information for a give build URI:

        using (TfsTeamProjectCollection Tfs = new TfsTeamProjectCollection(…)
        {
            Uri myBuild= new Uri(… some build URI…);
            TestManagementService tcm = (TestManagementService) Tfs.GetService<TestManagementService>();

            ITestManagementTeamProject teamProject = tcm.GetTeamProject(… Team Project Name…);

            foreach (var testResult in teamProject .TestRuns.ByBuild(myBuild))
            {
                testResult.Statistics.CompletedTests;
               
            }
        }

With SP1 of Visual Studio and the Team Client, Code Coverage results by build or test run has been exposed as the CoverageAnalysisManager property off ITestManagementTeamProject.

namespace Microsoft.TeamFoundation.TestManagement.Client
{
    public interface ICoverageAnalysisManager
    {
        IBuildCoverage[] QueryBuildCoverage(string buildUri, CoverageQueryFlags flags);
        ITestRunCoverage[] QueryTestRunCoverage(int testRunId, CoverageQueryFlags flags); 
    }
}

So now, if you want extend the example above to iterate thru the Assembly (Module)level Code Coverage information:

foreach (IBuildCoverage coverage in teamProject.CoverageAnalysisManager.QueryBuildCoverage(myBuild.ToString(), CoverageQueryFlags.Modules))
{
    foreach (IModuleCoverage moduleInfo in coverage.Modules)
    {
        moduleInfo.Name;
        moduleInfo.Statistics.BlocksCovered;
        moduleInfo.Statistics.BlocksNotCovered;
        moduleInfo.Statistics.LinesCovered;
        moduleInfo.Statistics.LinesNotCovered;
        moduleInfo.Statistics.LinesPartiallyCovered;
    }
}

MVCConf Materials: Industrial Strength NuGet

Want to again shout out to The Hex, Eric Hexter,  for getting me involved, coordinating, guiding, all that good stuff .  And thank you those that attended.

Link to the basic materials –> (http://tinyurl.com/4m7exyo)

1. Build.zip:  The AndyWahr.NuGet.sln contains the BuildHelpers (custom workflow assemblies), the BuildTemplate project (for visual editing of the build Workflow), and NuGet-Project (nuget package for creating nuget’s).
2. Widgets.com.zip:  Simulated project of a consumer of a NuGet.
3. Widgets..Framework.zip:  Simulated solution of a Framework team that produces a NuGet for other teams.
4. Industrial Strength Nuget.pptx:  Deck for the presentation.

I’ll be posting over the next little bit full details that went into the demo:

1. Setup of the environment
2. Detail view of the custom workflow
3. More info about the process.

Stay Tuned!

Base Team Build Directories Setup

So you want to setup a Build server, sounds easy doesn’t it?  It actually is, just need to account for a few little details, primarily 2 directories, the build working directory and the build drops directory.  The biggest killer of a build server is the infamous MAX_PATH limitation, limiting files on disk to 260 characters or less:

Setup your build working directory. 

You’re build agents need a temporary workspace to build from.  The Build Agent definition has a “Working Directory” setting that is the base for this.  One thing to note is a sources subdirectory is added to that directory you specified, which will go into the overall path length (aka MAX_PATH limitation).  The Work directory field has some interesting macros to use for creation of unique base folders to allow multiple agents to run multiple build definitions on the same box.  As with all thing, THOU SHALL NOT PUT THIS ON THE SYSTEM DRIVE.  A child cries every time either a build directory or the build drops directory is defined on the same drive letter as the OS, most of the time the C drive. 

My preference is to use the numeric ID’s TFS assigns to the build agent and the build definition to segregate these folders.  I will use the D drive as my example non-system drive I use for data.  Make a directory called D:\bld and give full rights to the service account running the agents on that machine:

Working Directory = D:\bld\$(BuildAgentId)\$(BuildDefinitionId)

What you will see = D:\bld\5\3  (the 5th build agent building the 3rd definition)

Setup your build drops directory and share.

Sometimes this is on your build machine, sometimes its on file server.  The key is this needs to be a file share where the full UNC is in the build definitions.  The key thing to remember is the build service account needs full rights both the file system where the share exists and the network share (thru Advanced Settings on the sharing dialog).

How to build Visual Studio 2010 Extensions thru 64bit Team Build

There has been a lot of great things added to Visual Studio 2010, specifically around creating custom Add-in/Extensions/Tool Windows/etc..  You download the Visual Studio 2010 SDK and off you go enhancing your development experience.

The one challenge I’ve had is trying to get these extensions to build thru Team Build 2010.  First few times I didn’t really bother with it to much, just chalked it up to something strange in the way the SDK does the packaging.

I started to dig into it and hit this little article.  So I logged onto my build box, opened a Visual Studio 2010 Command prompt, and it built from my command prompt.  Hmmm interesting.

Then my friend, the “where” command, tells me I’m running the 32bit version of MSBuild.  Of course since the default Visual Studio 2010 Command Prompt sets you up with the 32bit environment variables.  Makes sense.  DevEnv (Visual Studio main program) is also currently only 32bit.

So as an experiment, since the builds I’m doing don’t require to compile for x64, I found where to tell Team Build to use the 32bit version of MSBuild instead of defaulting to the version of the host process (aka 32bit for Visual Studio and CMD.EXE, 64bit for Team Build).

Open up your Build Workflow in Visual Studio and:

• Open Sequence
• Open Run On Agent
• Open Sequence
• Open Compile, Test
• Open Try Compile and Test
• Open Compile and Test
• Open For Each Configuration….
• Open Compile and Test….
• Open For Each Project in BuildSettings.ProjectsToBuild
• Open Try To Compile the Project

You should see something like this:

Right Mouse click on “Run MSBuild for Project”

Change the ToolPath variable to the 32bit directory for .Net (C:\Windows\Microsoft.NET\Framework\v4.0.30319 for example).

And your off!

What is a Build Master

“There is a reason why Garbage Men have a title of Sanitation Engineer…”

For a non-software shop, the function of Build Master is that bridge  from Development to Operations/Infrastructure/Support, build just happens to be the primary function or output that is produced.  Think of it this way, successful projects are ones that deploy on time.  Projects deploy successfully when the software/solution is designed for deployment.  A Build Master is a person that can bring that operational/infrastructural/support perspective into the Development world.

Sounds like lots of fluff, but in reality primary technical resources on projects (Architects/Lead Devs/etc…) have enough on their plate from business/technical requirements, specifics of the technology being used, individual team members interpretation of design, tap dancing for management, that having an individual to be that check point provides a significant value.

Build Masters should be a strong technical resource, with an Application Development background and some Infrastructural Experience.  This is a real tweener role, plugging in gaps based on the strengths/weaknesses of the team. Sometimes you spend most of your time staring at build consoles and sometimes you are building dev and test environments while troubleshooting code.

A Build Master is not just a build script jockey, although a proper automated build (both CI and BigBuild) that exercise Unit testing, packaging, and deployment are vital.

It can be quiet an entertaining position and quiet effective if staffed and positioned correctly.  The best part of this role is that people generally view Development as the only variable part of the project.  Builds and Deploys are viewed like your car, I just put me key in, start it, and go.  The number of times I’ve been in the meetings when things go bad during a (and of course it’s a deployment issue).  There are times where it is an issue with build and deploy, but generally the issue comes to what was provided in either source, process, or documentation.  I get to reintroduce the term GIGO, you get out what you put in.  Part of what makes Build Master successful is that person’s ability to push back on the development teams for a better overall solution.

Ok enough soap box rhetoric, promise for some useful posts around TeamBuild 2010 and all the different ways we can figure out how to copy files.

Here we go….

My name is Andy Wahrenberger, I’m a recovering Application Developer turned Build Master.  I spent the first almost 10 years of my career with head buried in my own troubles.  I then was smart (or stupid based on your perspective) to own up to the ability to write a batch files that could kick off a build.  That had led me down this, the Build Master path.

Caveat:  I am not claiming to be the Build Master supremo, far from it.  I’ve been fortunate enough to have experience a variety of different situations/combinations of technologies that I have been encouraged to start sharing my fun.

My focus has been primarily on the Microsoft stack of technologies, focusing on ALM/Build/Deploy solutions using Team Foundation Server since Beta1 of TFS 2005.  The before time, the libraries of batch files and custom tools, aren’t really so interesting anymore.