.NET@mobile – #2: Infrastruktur für Developer (IDE, TFS)

Nach einiger Zeit des Arbeitens, Wartens und Harderns nun der 2. Teil der begonnenen Serie zum Thema Xamarin und der Einbindung in die Unterschiedlichen Umgebungen. Hier möchte ich mich auf die Infratruktur und auf etwas außergewöhnlichere Themen, wie TFS konzentrieren.

Inhalte

Teil 1: Einführung in App-Entwicklung und Xamarin

Teil 2: Infrastruktur für Developer (IDE, TFS)

Teil 3: Design von Projektmappen

Teil 4: Publishing

Webcast

Erstmal eine kleine Sensation vorweg: Die Webcasts werden ab sofort in Englisch angeboten. Der Hintergrund ist der, dass ich einen Haufen traurige Feedbacks auf Facebook bekommen habe, weil ich die Videos in Deutsch statt Englisch anbiete. Auf der anderen Seite war kein Kommentar dabei, der mich für die deutsche Bereitstellung gelobt hätte. Der Text bleibt allerdings in Deutsch, sodass ich denke, dass der linguistische Verlust verschmerzbar bleibt (an einigen Stellen im Cast kommen dafür eingedeutschte Oberflächen :-)).

Was man alles braucht

Als allererstes ist mal ein Mac anzuschaffen. Es ist zwat schon so, dass man das Xamarin Studio inzwischen auch auf einem PC in das Visual Studio integrieren kann, allerdings sucht dieses gleich nach einem „Mac Build Server“. Das ist, vereinfach ausgedrückt, ein Apple-Rechner (Mac) mit installiertem XCode und darauf aufsetzendem MonoTouch. Letztlich benutzt auch ein Windows-Xamarin diesen dann später über das Netzwerk, um seine Build-Prozesse laufen zu lassen.

Ich selbst nutze derzeit einen 27″-iMac mit 16 GB RAM und SSD. Ich habe nicht das aktuellste Modell, sondern den „fetten“ Vorgänger. Die Entwicklung, das Debugging und die Builds laufen flüssig. Einige Tests mit MacBook Pro und Mac mini haben keine signifikanten Unterschiede gezeigt.

Auf dem Mac selbst muss wie gesagt erstmal die Apple-Hausentwicklungsumgebung eingerichtet werden. Damit man hier vernünftig entwickeln kann, ist fast zwangsläufig eine Registrierung als Apple Developer notwendig. Das kostet 99 $ p.a. und man bekommt dadurch neben der Software und den SDKs vor allem auch die dringend benötigten Zertifikate, um die fertigen Apps dann auf Testflight oder gar in den Apple-Store zu bekommen.

Jetzt kommt die Windows-Welt an die Reihe. In meinem Fall kommt als erstes das Visual Studio 2012 drauf. Dann wird das Xamarin Studio installiert. Das Studio integriert sich bei dieser Installation komplett ins VS. Vor der Installation sollte man übrigens am besten sicherstellen, dass der spätere Build-Mac eingeschaltet und vom Windows-Rechner aus zu „sehen“ ist.

Das Xamarin Studio landet dabei übrigens trotzdem auch als eigenes Programm auf der Platte. Wer also gar nicht im Studio arbeiten möchte, kann auch glücklich werden.

Visual Studio Integration

Nach dem ersten Start des Visual Studio nach der Xamarin-Installation sollte man dem Studio kurz Zeit lassen. Das Output-Snapin sollte am besten aufgemacht werden.

Zu sehen ist nach der Installation nicht viel. Irgendwann könnte höchstens ein Fenster aufgehen, dass nach den Login-Informationen des Xamarin-Accounts fragt. Hat man diese eingegeben, wird nach kurzer Wartezeit ein Dialog für die Auswahl des zu verwenden Mac-Build-Servers erscheinen. In diesem Fenster kann man dann aus einer Liste von gefundenen Systemen auswählen.

Wer diesen Assistenten aus Versehen oder absichtlich abbricht, kann später trotzdem alles einrichten. Zunächst einmal hat das Tools-Menu des Visual Studio einen neuen Menu-Punkt:

Abb. 1: Xamarin-Menueintrag
Abb. 1: Xamarin-Menueintrag

Hierüber kann man die Account-Informationen eingeben oder einsehen. Viel wichtiger ist aber dann doch die Erweiterung des VS-Options-Dialoges:

Abb. 2: Optionsdialog in VS
Abb. 2: Optionsdialog in VS

Die Schaltfläche Configure erlaubt es hier, nachträglich noch die Einrichtung des Build-Rechners durchzuführen:

Abb. 3: Build-Mac auswählen
Abb. 3: Build-Mac auswählen

Die Pferdefüße

Die Integration ins Studio ist also erstmal gelungen. Bei der täglichen Arbeit muss man sich allerdings mit ein paar kleinen Ärgernissen herumschlagen. Zunächst einmal ist da eine deutliche Verlangsamung des Ladens von Solutions, die MonoTouch-Projekte beinhalten festzustellen. Das liegt vermutlich daran, dass das VS bei solchen Projekten erstmal eine Verbindung zum Build-Mac aufbaut und dann z.B. prüft, ob die Version von Monotouch auf dem Windows-Rechner mit der auf dem Mac übereinstimmt.

Findet das Visual Studio eine neuere Version, bietet es ein Update an. Allerdings erfordert dies i.d.R. immer einen Neustart des Studios, was auch nervig werden kann.

Ein Feature, dass ich gar nicht zum Laufen bringen kann, ist das Debuggen aus dem Visual Studio heraus. Wenn ich also ein MonoTouch-Projekt als Startprojekt anlege und dann F5 drücke, ist das erwartete Verhalten, dass auf dem Build-Mac der Simulator startet und ich aus dem VS heraus debuggen kann. Das klappt schonmal nicht. Er „zuckt“ kurz los und beendet dann die vshost mit Code 0 ohne weiteres Ergebnis.

Warten auf Portable

Xamarin selbst hat angekündigt, irgendwann einmal die relativ neuen Portable Libraries im Visual Studio zu unterstützen. Gerade im Umfeld der Mobilentwicklung machen die PCLs so richtig Sinn. Xamarin geht auf plattform-übergreifende Entwicklung in einem eigenen Beitrag ein. Dort ist dann zu lesen:

Xamarin’s support for Portable Class Libraries is currently under development.

Ich habe mich entschieden, die ebenfalls dort beschriebenen Tricks mit Dateiverknüpfungen etc. erstmal nicht auszuprobieren, da es hier immer wieder zu Problemen kommt, wenn man in größeren Projekten mit meheren Leuten arbeitet. Es funktioniert in Grundzügen allerdings bereits recht gut. Hier mal ein kleiner Extrakt zur Einrichtung.

Bevor es losgehen kann, muss man eine neue XML-Datei „MonoTouch.xml“ im Ordner

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\SupportedFrameworks

anlegen:

<?xml version="1.0" encoding="UTF-8"?>
<Framework MinimumVersion="4.0" MaximumVersion="*" Profile="*" Identifier="MonoTouch" DisplayName="MonoTouch"/>

Sobald man das getan hat und dann im Visual Studio ein neues Projekt vom Typ „Portable Class Library“ erstellt, wird im dann erscheinenden Dialog auch MonoTouch angeboten:

Abb. 3: PCL für MonoTouch
Abb. 3: PCL für MonoTouch

Wichtig ist, dass bei Windows Phone mindestens Version 7.5 eingetragen ist. Eine PCL ist eine Bibliothek, die die internen Verweise so organisiert, dass der größte gemeinsame Nenner der im Dialog Abb. 3 angehakten Zielframeworks unterstützt wird. Hat man die Bibliothek einmal angelegt, kann also aus verschiedenen Zielprojekten darauf verwiesen werden. Hier mal ein kleines Beispiel dazu (mehr wird es im Folgeartikel geben):

Abb. 4: Solution inkl. PCL
Abb. 4: Solution inkl. PCL

TFS

Wir bei codingfreaks können Tools eigentlich immer nur effektiv einsetzen, wenn die Teamzusammenarbeit in irgendeiner Form geregelt ist. Xamarin selbst bietet hier von Haus aus nicht die Lösung für den TFS an. Solange wir hier das Plugin fürs VS betrachten, brauchen wir ja auch keine solche, weil wir ja hier den Team Explorer nutzen können. Auf dem Mac benötigen wir allerdings schon eine teamfähige Vorgehensweise.

Hier springt eine Eigenentwicklung aus Redmond in die Bresche: Team Foundation Everywhere. Hierbei hadelt es sich um ein Plugin für Eclipse, das Microsoft selbst bereit stellt, um auch Nicht-Windows-Usern vollen Zugriff auf den TFS zu geben. Für diejenigen, die es selbst schnell ausprobieren wollen:

  1. Eclipse starten
  2. Im Hilfe-Menü unter im Bereich Software hinzufügen die URL „http://dl.microsoft.com/eclipse/tfs“ auswählen

Der Rest läuft automatisch ab.

Zwei Dinge ist hier aber gerade für Team-Explorer-Verwöhnte unbedingt zu beachten! Wenn man nun ein Xamarin-Projekt öffnet, das im TFS gehostet ist, muss man vorher natürlich Eclipse starten und auschecken. Viel wichtiger aber ist, dass man Dateien, die man im Xamarin Studio dem Projekt hinzugefügt hat händisch dem TFS mit übergeben muss. Das liegt daran, dass es halt keinen Team Explorer im Xamarin Studio gibt und der TFS Everywhere nicht „mitbekommt“, dass man neue Elemente in der Solution hat. Die Synchronisation erledigt hier der Entwickler.

Git

Für viele Entwickler außerhalb von Unternehmens-Strukturen wird Git als Quellcodeverwaltung immer interessanter. Microsoft hat den Trend auch erkannt und bietet ja mittlerweile eine native Git-Unterstützung im Team Explorer an. Auch Xamarin-Studio kennt Git und somit erreicht man hiermit eine komplette Einbindung ohne die im TFS notwendigen „Klimmzüge“.

Ich würde nur den TFS nicht allzu schnell verwerfen, weil es neben der Quellcodeverwaltung noch einiges mehr an Todos in gemeinsamen Projekten gibt. Als Stichworte seien hier nur automatische Builds, WorkItem-Tracking usw. genannt.

Sonstige Integration

Xamarin ist derzeitlich ziemlich rührig, was die Angleichung der Tools an den aktuellen VS-Standard angeht. Nuget 2.5 bringt z.B. erstmals Unterstützung für MonoTouch mit, sodass wir auf unsere geliebten install-package-Kommandos nicht mehr verzichten müssen. Auch von der anderen Seite naht Schützenhilfe. Offensichtlich hat Scott Hanselman ein wenig nachgeholfen und das SignalR-Team hat sich bemüßigt gefühlt, Xamarin nativ zu unterstützen. Das ist wichtiger, als es sich im ersten Moment anhört, weil man über die Socket-basierten Ansätze von SignalR ernst zu nehmende Alternativen zu den Push-Notifications der Plattform-Anbieter umsetzen kann.

Wer dachte, dass Xamarin eher ein Nischendasein fristet, den wird vielleicht die Tatsache, dass Scott selbst auf der Evolve aufgetreten ist ein wenig die Augenbrauen heben lassen.

Eine Antwort auf „.NET@mobile – #2: Infrastruktur für Developer (IDE, TFS)“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.