Windows Store App mit TFS 2013 und Hosted Build Controller erzeugen

VS_BuildManagement[Update 29.04.2014] Durch die Verwendung des TFS 2013.2 wird das Erstellen eines Hosted Build Controllers in Microsoft Azure, um Windows Store Apps zu bauen, wesentlich einfacher. Nach der Installation und Konfiguration des TFS 2013 Build Controllers auf dem VM Server, mussten lediglich die fehlenden Visual Studio 2013 Komponenten (siehe Schritt 4) installiert werden und der Build konnte erfolgreich durchlaufen. Also los! Upgraden auf TFS 2013!

Windows Store Apps mit dem Team Foundation Server zu erstellen ist eigentlich einfach – solange man die empfohlenen Komponenten verwendet. Da ich die Voraussetzungen gerade nicht erfüllen konnte (und auch zu ungeduldig war auf meinen Admin zu warten), suchte ich nach einer möglichen Alternative. Ich erstellte in Microsoft Azure eine Virtuelle Machine mit Windows Server 2012 R2, installierte dort einen TFS Build Controller und baute anschließend meine Windows Store Apps über diesen Hosted Build Controller. Und so hab ich es gemacht:

Um Windows Store Apps zu erzeugen wird im MSDN das Betriebssystem Windows 8 als Voraussetzung genannt. Für Windows Store 8.1 Apps sogar Windows 8.1. Die Build Server, die mir zur Verfügung standen, waren alle mit dem Windows Server 2012 OS ausgestattet und einen anderen Rechner hatte ich auch nicht parat. Also was tun?

Schritt 1: Virtuelle Maschine in Microsoft Azure erstellen

Ich hatte also nun zwei Möglichkeiten – a) warten bis mir mein Admin einen entsprechenden Server zur Verfügung stellt oder b) meinen Microsoft Azure Account nutzen und mir meine eigene virtuelle Maschine (VM) erstellen. Wie gesagt, ich war ungeduldig und so entschied ich mich für die zweite Möglichkeit. Das wollte ich ohnehin schon mal ausprobieren.

HostedCloudServices

Abbildung 1: Hosted Build Controller mit Microsoft Azure

Das Erstellen einer VM in Azure ging wirklich erstaunlich einfach. Ich meldete mich mit meinem Microsoft Account auf windowsazure.com an und erstellte mir einen Virtuellen Computer über den Katalog.

Hinweis: Die Kosten für die Nutzung von Microsoft Azure könnt ihr über einen Preisrechner selbst herausfinden.

AzureVM I

Abbildung 2: Virtuellen Computer in Microsoft Azure erstellen

Blöderweise hat der VM-Katalog auch keine Client Betriebssysteme im Angebot. Also entschied ich mich für die Erstellung einer virtuellen Maschine auf Basis von Windows Server 2012 R2. Ich dachte, so schwer kann es ja nicht sein trotzdem einen TFS Build für Windows Store  Apps zum Laufen zu kriegen.

AzureVM II_Abbildung 3: Betriebssystem aus Katalog wählen

Der Konfigurator macht es einem einfach – virtuellen PC auswählen, Namen des PCs bekanntgeben,  Größe (Anzahl CPUs und RAM) wählen, Benutzername mit Passwort vergeben und ein paar andere Einstellungen vornehmen. Fertig. Zugegeben, ein paar Minuten musste ich schon warten bis die Maschine fertig konfiguriert war, aber dann konnte ich loslegen.

AzureVM VI_runningAbbildung 4: Virtueller Computer einsatzbereit

Schritt 2: TFS Build Controller installieren

Da mein Projekt von einem Team Foundation Server 2012 gehosted wird, musste ich auch auf dem Azure-VM Server einen TFS 2012 Build Controller installieren und konfigurieren.

Die Installation ist unspektakulär, interessant wird es erst bei der Konfiguration. Um einen Build Server (Controller und Agents) zu erstellen, wählte ich im Configuration Center „Configure Team Foundation Build Service“ und stellte eine Verbindung zu meinem Team Foundation Server her.

AzureVM X_ Connect to TFSAbbildung 5: Build Controller konfigurieren

Anschließend konfigurierte ich einen Controller und einen Build-Agent auf der Maschine und ließ den Configuration Wizard seinen Job machen.

AzureVM XIV_Build AgentsAbbildung 6: Hosted Build Controller Konfiguration

Schritt 3: Erster Test fehlgeschlagen

Nachdem ich nun einen Build Controller auf der Azure-VM zur Verfügung hatte, stellte ich meinen Test-Build entsprechend ein und wählte in der Build Definition unter „Build Defaults“ den almsports2013 Build Controller aus. Aber leider scheiterte der Build beim ersten Mal Ausführen mit der Fehlermeldung:

The imported project „c:\program files (x86)\MSBuild\Microsoft\WindowsXaml\v11.0\Microsoft.Windows.UI.Xaml.CSharp.targets“ was not found. 
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

AzureVM XV_Error1Abbildung 7: Build Fehlermeldung über fehlende MSBuild Targets

Zugegeben, der Build konnte nicht funktionieren. Der Ordner WindowsXaml war schlichtweg nicht auf dem Build-Server zu finden.

Schritt 4: Visual Studio installieren

Die Fehlermeldung deutete darauf hin, dass MSBuild einige relevante Targets nicht finden kann. Vermutlich weil ich auf einem Server Betriebssystem die Store Apps bauen wollte und nicht wie empfohlen auf einem Client Betriebssystem. In einem Blog Beitrag zum Thema Hosted Build Controller von Simon Middlemiss fand ich einen Hinweis darauf, dass man zum Erstellen von Windows 8 Apps die Visual Studio Komponenten Tools for Maintaining Store Apps for Windows 8 und Windows Phone 8 SDK installieren sollte.

AzureVM XVII_InstallVS_Components

Abbildung 8: Komponenten von Visual Studio 2013 installieren

Da es die Komponenten erst mit Visual Studio 2013 zur Auswahl gibt, installierte ich Visual Studio 2013 und siehe da, die fehlenden MSBuild Targets tauchten auf.

ABER: die Komponenten lagen nun im Unterordner v12.0 und nicht v11.0, so dass der Test-Build immer noch am Auffinden der Komponenten scheitert. Mist! Hätte ich doch nur einen TFS2013, der würde bestimmt nicht in einem Unterordner v11.0 nach Komponenten suchen…

Also gut, was tun? Auch noch ein Visual Studio 2012 installieren? Visual Studio 2013 wieder deinstallieren? Ich beschloss Visual Studio 2012 zu installieren, so ging ich wenigstens sicher, dass im geforderten Ordner c:\program files (x86)\MSBuild\Microsoft\WindowsXaml\v11.0 auch alle v11.0 Targets vorhanden sein werden. Visual Studio 2013 ließ ich erstmal auf dem Rechner – das sollte sich später glücklicherweise als richtig herausstellen.

Schritt 5: Build Template Anpassen

Nachdem ich das Problem mit den MSBuild targets gelöst hatte, wurde ich schon mit der nächsten Herausforderung konfrontiert. Der Test-Build meldete den nächsten Fehler:

Unknown type ‘ThemeResource‘ in XML namespace http://schemas.microsoft.com/winfx/2006/xaml/presentation. 

AzureVM XIX_Error2Abbildung 9: Build Fehlermedlung Unknown type ‚ThemeResource‘

Nach etwas Recherche fand ich heraus, dass das Build Template des TFS 2012 leider keine Windows 8.1 Apps erstellen kann und man dafür besser das neue TFS Build Template TfvcTeamplate.12.xaml verwenden soll. Leider funktioniert dieses Template nur mit dem TFS2013.

Im MSDN fand ich einen Eintrag zum Thema „Use an earlier build process template to build some kinds of Visual Studio Team Foundation Server 2013 apps“. Darin wird beschrieben, dass man in älteren Build Templates den MSBuild ToolPath anpassen kann, damit dieser die richtigen Komponenten zum Bauen von Windows 8.1 Store Apps findet. Und als eine Voraussetzung für die Verwendung des benötigten ToolPath wurde die Installation von Visual Studio 2013 genannt. Gut, dass ich das schon installiert hatte.

AzureVM XX_Template anpassenAbbildung 10: ToolPath von MSBuild ändern

Ende gut, alles gut! Nachdem ich den ToolPath im Build Template angepasst hatte, konnte ich den Test-Build erfolgreich durchführen und meine Windows 8.1 Store App wurde gebaut.

AzureVM XXI_BuildSucceedAbbildung 11: Erfolgreicher Build einer Windows 8.1 Store App

Zugegeben, das Szenario ist etwas ungewöhnlich, aber vielleicht steht der eine oder andere vor einem ähnlichen Problem und kann sich durch diesen Post etwas Suche ersparen.

Ich werde demnächst testen, ob es mit dem TFS 2013 als Plattform einfacher zu realisieren ist. Ich bin gespannt.

[0] http://blogs.msdn.com/b/mcsuksoldev/archive/2014/02/12/hosting-a-tfs-build-controller-on-windows-azure-and-connecting-to-visual-studio-online.aspx

[1] http://msdn.microsoft.com/de-de/library/dd647548.aspx#older_process_template