Ich werde immer wieder darauf angesprochen, dass ich doch einen Mac nutze, um dann gefragt zu werden, wie das denn eigentlich mit der .NET-Entwicklung sei. Dem möchte ich hier kurz Rechnung tragen.
Nach einem ersten gescheiterten Versuch im Sommer 2006 habe ich vor knapp einem Jahr einen zweiten Anlauf genommen und mir ein MacBook zugelegt. Grund war nicht nur, dass ich spätestens seit den angedrohten Wegwerf-Lizenzen für Windows vor der Einführung von Vista 2006 gerne zweigleisig fahren und so meine Abhängigkeit von Microsoft verringern möchte. Es war auch die Qualität der Hardware, die meiner Meinung nach von keinem einzigen PC-Hersteller bei vergleichbaren Preisen geschlagen oder ausgeglichen werden kann. Das Unibody-Gehäuse des MacBook setzt einfach neue Maßstäbe, davon bin ich überzeugt.
Aber zurück zur Entwicklung. Grundsätzlich gibt es heute 3 Möglichkeiten, Software und Websites mit .NET am Mac zu entwickeln:
1. Mono
Mono wird, angetrieben und finanziert von Novell, immer erwachsener und ich möchte nicht ausschließen, dass es sich mittelfristig zu einer echten Alternative, vor allem unter Linux, entwickeln kann. Seit Kurzem gibt es auch MonoDevelop, die dazugehörige Entwicklungsumgebung, für den Mac. Leider funktionierte das Ding bei mir nicht - beim ersten Versuch ließ es sich gar nicht erst starten, beim zweiten Versuch (nach einer zwischenzeitlichen Neuinstallation des gesamten Rechners) klappte der Start und es rauchte erst beim Öffnen von einzelnen Dateien ab. Zwischenfazit also: derzeit noch nicht brauchbar.
2. Bootcamp
Bootcamp bezeichnet im Prinzip nur ein Set von Treibern, welche durch Apple für Windows bereitgestellt werden. Damit lässt sich Windows also parallel oder als Ersatz für OS X auf dem Mac installieren. Das ist seit der Umstellung auf die Intel-CPUs kein Problem mehr, denn seitdem ist ein Mac auch nur noch ein PC ...
Der Vorteil liegt hier vor allem darin, dass man keinerlei Geschwindigkeitseinbußen zu verzeichnen hat, da Windows nativ ausgeführt wird. Wer also nur eine schicke Hardware haben möchte und sonst mit Windows leben kann, oder wer mit der Einschränkung des Reboots leben kann, um Software zu entwickeln, für den ist das eine Option. Dann gibt es im Vergleich zu einem normalen Windows-Rechner auch nichts weiter zu beachten, außer dass man entsprechend viel Speicherplatz auf der Platte/SSD benötigt.
3. Virtualisierung
Wer jedoch wie ich gerne mit Mac OS arbeitet, und das werden die meisten tun, wenn sie es einmal ohne Vorbehalte ausprobiert haben, für den ist die Virtualisierung wohl eher eine geeignete Option. Denn man spart sich damit nicht nur den zeitaufwendigen Reboot, sondern man kann auch gleichzeitig mit seinen sonstigen Apps weiter arbeiten und muss nicht alles zweimal installieren (z.B. Mailanwendung oder Chat-Client). Und man kann, was man nicht vergessen darf, auch auf alle Files des Macs vom virtualisierten Windows aus zugreifen und umgekehrt. Etwas, was unter einem nativ gebooteten Windows nur mit Handständen zu machen ist.
Welche Software sollte man für die Virtualisierung nehmen?
Das hängt ganz vom persönlichen Geschmack und Geldbeutel ab. Vor einem Jahr habe ich mich nach einem Vergleich zwischen VMware Fusion und Parallels für Letzteres entschieden, weil es mir damals eindeutig schneller erschien.
Vor ein paar Monaten hingegen habe ich erneut VMware Fusion probiert, was zu diesem Zeitpunkt definitiv sehr viel schneller und weniger Ressourcen-bindend war als Parallels, also bin ich umgestiegen und auch bis heute dabei geblieben. Ich bin damit sehr zufrieden - insbesondere auch das Stoppen und Starten von VMs klappt damit reibungslos und fix.
In jedem Fall sollte man die aktuellsten Versionen verwenden. Sowohl Parallels als auch VMware Fusion stehen seit Kurzem in neuen Versionen zur Verfügung. Als dritten Player könnte man noch VirtualBox von Sun dazunehmen, wobei ich die Software am Mac bisher noch nicht probiert habe (unter Windows ist sie klasse und sehr schnell).
Wie klappt die Integration?
Man kann sowohl mit VMware als auch mit Parallels seine Windows-Installation sowohl in einem Fenster, wie im Screenshot zu sehen, als natürlich auch Fullscreen oder aber integriert verwenden. "Integriert" meint, dass das virtualisierte Windows mit dem Host-MacOS "verschwimmt", man kann also beispielsweise sowohl die Windows-Taskleiste als auch das Mac-Dock verwenden und ein Windows-Internet-Explorer-Fenster neben einem Mac-Safari-Fenster geöffnet haben.
Für mich ist das bis heute nichts als eine nette Spielerei, die ich aus Performance-Gründen, übrigens genau wie Aero unter Windows in der VM, nicht verwende. Das liegt aber auch daran, dass ich die Werkzeuge genau trennen kann. Für Leute, die gleichzeitig mit Mac- und Windows-Anwendungen arbeiten, mag das eine gute Option sein.
Und die Performance?
Die Geschwindigkeit lässt sich zwar bis zu einem gewissen Grad durch die Wahl der VM-Software beeinflussen, letztendlich geht aber nichts über ausreichend Hardware. Ich selbst verwende ein MacBook mit einem 2,4 GHz Intel-Core-2-Duo-Prozessor und 4 GB DDR3-RAM. Die 4 Gigabyte Arbeitsspeicher sind ein Muss - werden aber von allen aktuellen Geräten unterstützt und lassen sich leicht und günstig nachrüsten.
Viel entscheidender ist aber die Wahl der richtigen Festplatte bzw. Solid State Disk. Ich habe ein halbes Jahr lang mit einer Festplatte und der VM gearbeitet - was leidlich ging. Richtig Spaß begann es aber erst zu machen, als ich im Sommer eine 120-GB-SSD von OCZ reingesteckt habe. Die liefert richtig Performance.
Zwar bietet Apple für Snow Leopard im Gegensatz zu Microsoft mit Windows 7 noch immer keine native Unterstützung für den TRIM-Befehl, der dafür sorgt, dass die Disks nicht kleiner und langsamer werden. Doch existiert unter anderem für die OCZ-SSDs mittlerweile Firmware mit einer eingebauten Garbage Collection, die die Disk in Ruhezeiten "aufräumt" und so für einen Erhalt der Geschwindigkeit sorgt.
Mit dieser Konfiguration erhalte ich auf meinem Mac eine Geschwindigkeit, die ausreichend ist um die meisten Projekttypen und Anwendungen mit Visual Studio in der VM zu bearbeiten. Auch Website-Projekte oder viele Unit-Tests oder die Verwendung des WinForms-Designers stellen kein Problem dar.
Aber natürlich kann ein virtualisiertes Windows nie so schnell sein wie ein nativ laufendes Windows auf der gleichen Hardware. Wer also nervös wird, wenn Visual Studio mit ReSharper 5 Sekunden länger beim Öffnen eines Projektes braucht, sollte überlegen auf die Bootcamp-Variante zurückzugreifen. Leider braucht das sehr viel Platz und die SSDs sind heute noch nicht wirklich günstig ...
Fazit
Windows- bzw. .NET-Entwicklung am Mac? Das ist heute absolut kein Problem mehr. Sowohl Hard- als auch Software sind nun endlich soweit ausgereift, dass man das Experiment problemlos wagen kann.
