© Sergej Razvodovskij, 123RF

Seit Ende April können sich Interessierte die Entwicklungsumgebung Visual Studio Code von Microsoft als Freeware in der Preview-Version 0.3.0 auch für Linux herunterladen. Windows-Entwickler Michael Kißling schaut, was bereits unter Linux läuft und wo es noch klemmt.

Der offizielle Linux-Support erscheint mir in der Tat als eine kleine Revolution, hatte sich Microsoft doch bis dato in Sachen Entwicklung nur auf die Windows-Plattform fokussiert. Die Gründe für den Strategiewechsel liegen auf der Hand: Microsoft möchte seine Dotnet-Plattform [1] auch in anderen Betriebssystemwelten etablieren (Abbildung 1).

Abbildung 1: Ungewohnter Anblick: Microsoft bietet Software für die Linux-Plattform an.

Das macht schon die Featureliste von Visual Studio Code (VSC, [2]) deutlich. Die Software unterstützt zwar mehr als 30 Programmiersprachen, bietet aber für die meisten nur Syntax Highlighting und Klammern-Ergänzung an. Aufwändige Features wie Refactoring, Code-Analyse und Intellisense gibt es nur für die Microsoft-eigenen Sprachen C# und Typescript sowie für Webtechnologien wie CSS, HTML, Javascript und Json (Abbildung 2). Die Features von VSC richten sich also in erster Linie an Webentwickler, die bereits mit C# gearbeitet haben oder es künftig tun möchten.

Abbildung 2: Aufwändige Features wie Refactoring und Code-Analyse gibt es nur für Microsoft-eigene Sprachen sowie für Webtechnologien.

Doch im selben Atemzug stellt sich mir auch die Frage, ob sich Microsoft damit nicht selbst Konkurrenz macht. Immerhin existiert bereits ein ausgereiftes Visual Studio für Windows [2], das sich nahtlos in die Windows-Plattform integriert. Warum also sollen Entwickler auf eine neue und noch recht wilde anstatt auf eine bewährte und umfassende Plattform setzen?

Der Preis ist heiß

Ein schlagendes Argument ist sicherlich der Preis. Linux-Server sind deutlich günstiger im Unterhalt als Windows-Server. Wer seine Webapplikation künftig auf einer Linux- statt auf einer Windows-Basis hosten möchte, will konsequenterweise auch die Software unter Linux entwickeln. Das verhindert einen technischen Bruch zwischen der Test- und Entwicklungsumgebung und dem späteren Produktivsystem.

Geht es nur um die reine Kostenersparnis beim Kauf der Entwicklungssoftware, bietet sich unter Windows der Einsatz der kostenlosen IDE Visual Studio Community [2] an, die über Visual Studio Code hinausgehende Möglichkeiten mitbringt. Für eine Vollversion von Visual Studio sind hingegen, abhängig von der gewählten Edition, bis zu vierstellige Beträge fällig.

Altlasten

Nun ist es aber gar nicht so trivial, eine vorhandene Windows-Webapplikation auf einem Linux-Server zu hosten, denn selten kommt so eine Applikation allein. Fast immer spricht sie auch Datenbanken und andere Dienste an. Die in der Windows-Welt kostenlose Datenbank Microsoft SQL Server Express [3], die sich reibungslos in die Microsoft-Infrastruktur einfügt, suchen Programmierer unter Linux vergeblich.

Der fehlende Microsoft SQL Server durchkreuzte so einst meinen Plan, die ASP-Net-Anwendung eines preisbewussten Kunden auf einem Linux-Server zu hosten. Der einzig gangbare Weg hätte darin bestanden, die Daten in eine andere Datenbank, etwa MySQL oder PostgreSQL, zu überführen.

Das aber wäre sehr aufwändig geworden: So hätte ich in T-SQL verfasste Stored Procedures komplett neu schreiben, proprietäre SQL-Funktionen für die Zieldatenbank umwandeln und die Datenzugriffsschicht im Code austauschen müssen. Das hätte auch Zusatzdienste wie die Reporting Services, Backupfunktionen oder Volltextindizes betroffen. Dient der SQL-Server also nicht als simple Datenablage, sondern nutzt er auch die umfangreichen Zusatzdienste, steigt der Migrationsaufwand deutlich.

Ähnliche Schwierigkeiten dürften Applikationen bereiten, die mit Windows-Diensten kommunizieren, etwa mit dem Windows Installer, Microsoft Silverlight, Report Viewer (ehemals Crystal Reports) oder mit Komponenten von Drittanbietern wie Telerik [4] oder Dev-Express [5]. Die Wahrscheinlichkeit, dass Entwickler ein vorhandenes und über die Jahre gewachsenes Windows-Projekt unter Linux weiterentwickeln, ohne diverse Windows-genuine Komponenten gegen ihre Linux-Gegenstücke austauschen zu müssen, scheint sehr gering.

Ein noch größeres Problem stellen Desktop-Applikationen dar. Für sie gibt es in der Microsoft-Welt zwei Technologien. Da sind zum einen die etwas älteren Windows Forms [6], zum anderen die Windows Presentation Foundation (WPF, [7]). Beide Technologien unterstützt Visual Studio Code nicht – es mangelt an einem grafischen Editor, mit dem der Windows-Entwickler seine Oberflächen gestalten kann. Mono [8] fehlen jedoch ebenfalls die Bibliotheken, um WPF-Anwendungen auszuführen. Immerhin lassen sich Windows-Forms-Anwendungen unter Mono betreiben.

Wer hingegen Webapplikationen mit der Microsoft-eigenen Technologie ASP-Net 5.0 [9] entwickelt, den unterstützt Visual Studio Code noch am stärksten. Hierbei handelt es sich um eine recht neue Technologie nach dem Model-View-Controller-Prinzip unter Einsatz diverser Javascript-Bibliotheken.

Eine ältere ASP-Net-2.0-Forms-Anwendung hat VSC im Test allerdings nicht mehr unterstützt. Auch wer mit der Software eine ASP-Net-4.0-Anwendungen öffnet, muss nacharbeiten, da ASP-Net 5.0 Projektdateien nun beispielsweise im Json-Format erwartet. Wie aufwändig eine Migration ist, bleibt abzuwarten: Im Moment existieren keinerlei Migrationstools für Visual Studio Code.

Linux und Dotnet

Wer in C# geschriebene Programme ausführen möchte, braucht für ausnahmslos alle eine spezielle Laufzeitumgebung. Diese kümmert sich um die notwendigen infrastrukturellen Aufgaben wie die Jit-Kompilierung, Speicherverwaltung und Fehlerbehandlung. Die meisten Windows-Rechner installieren das dafür nötige Dotnet-Framework von sich aus. Alternativ holt es ein Entwickler unkompliziert aus dem Internet nach.

Unter Linux gibt es das kostenlose Mono-Framework, ursprünglich ein Dotnet-Nachbau für die Linux-Welt. Den Kern des Dotnet-Framework (Dotnet Core) hat Microsoft unter die MIT-Lizenz gestellt, weitere Dotnet-Komponenten (Micro-Framework oder die Compiler Platform) stehen unter der Apache-2-Lizenz [10]. Davon profitiert unter anderem das Mono-Projekt.

Ein weiterer integraler Bestandteil des Dotnet-Framework ist der Internet Information Service (IIS), ein Webserver auf Windows-Grundlage. Unter Linux lassen sich Webseiten dagegen mit einem eigens entwickelten Webserver namens Kestrel [11] hosten, der ASP-Net unterstützt. Das Projekt befindet sich aber noch in einem frühen Entwicklungsstadium.

VSC im Praxistest

Als Basis für den Praxistest griff ich auf ein frisch installiertes Ubuntu 15.04 (64 Bit) zurück. Die Installation von VSC verlief problemlos: Zip-Datei herunterladen, entpacken, das Programm »code« starten – schon präsentierte sich VSC in einem für Visual-Studio-Nutzer eher ungewohnten Anthrazit (Abbildung 3).

Abbildung 3: Die Installation von Visual Studio Code gelingt problemlos, hakelig wird es danach.

Der erste Versuch, eine existierende ASP-Net-Anwendung als Solution (».sln« ) oder Projekt (».csproj« ) zu öffnen, schlug fehl: VSC erkennt weder Projektmappen noch Projekte. Vielmehr erwartet es einen Ordner, in dem sich die zu bearbeitenden Dateien befinden.

Wer diesen öffnet und damit beginnt, den vorhandenen Code zu bearbeiten, stellt schnell fest, dass VSC im ausgelieferten Grundzustand nicht mehr als ein besserer Texteditor ist. Codezusammenhänge wie Klassen und Namespaces erkennt es nicht, ein kontextbezogenes Intellisense oder die Echtzeiterkennung von Fehlern fallen damit flach. Nichts weist darauf hin, dass VSC versteht, dass es sich gerade in einem vorhandenen Projekt befindet. Ist das schon alles?

Externe Hilfe

Omnisharp (Abbildung 4, [12]) heißt ein Tool, das Intellisense für verschiedene Texteditoren wie Emacs, Atom, Brackets und eben auch Visual Studio Code bereitstellt. Omnisharp ist quelloffen, doch es sind auch einige Microsoft-Programmierer an dem Projekt beteiligt.

Abbildung 4: Omnisharp verspricht plattformübergreifendes Arbeiten mit Dotnet.

Das klingt nützlich, wirft aber auch gleich das nächste Problem auf, weil es ein Mono-Framework voraussetzt. Über das Ubuntu Software Center lässt sich Mono zwar unkompliziert installieren, allerdings nur in der älteren Version 3.2.8. Ein aktuelles Mono in Version 4.0 lief bei mir erst nach einigen Fehlversuchen. Letztlich musste ich haargenau den Anweisungen unter [13] folgen.

Nachdem ich das Mono-Framework 4.0 erst mal erfolgreich eingespielt hatte, arbeitete Omnisharp wie gewünscht. Es bietet Intellisense für eigene Klassen, aber auch für die des Dotnet-Framework. Zudem zeigt es, welche Programmteile implementierte Funktionen referenzieren, und springt bei Bedarf dorthin. Das ist sehr nützlich, um in größeren Projekten die Abhängigkeiten zu ermitteln, und gehört zum Standardrepertoire einer guten Entwicklungsumgebung.

Refactoring, also das automatisierte Aufräumen und Umschreiben von Code, unterstützt es rudimentär – hier konnte ich lediglich Funktionen und Klassen umbenennen. Als nützlich erwies sich, dass Omnisharp Software in Echtzeit kompiliert. Programmierfehler erkannte es sofort und unterstrich diese rot. Des Weiteren generierte es Codestrukturen wie For- und While-Schleifen automatisch.

Erste ASP-Net-Anwendung

Alle Zeichen deuten jedoch darauf hin, dass VSC in absehbarer Zeit nicht in der Lage sein wird, Dotnet-Projekte von Windows auf Linux zu migrieren. Zu stark scheint der Technologiebruch. Ein sinnvollerer Ansatz besteht darin, neue Programme mit Visual Studio Code zu entwickeln. Eine neue Technologie bedeutet oft auch einen Paradigmenwechsel, insofern ist es nur konsequent, alte Zöpfe abzuschneiden und mit einer neuen Anwendung zu starten.

Microsoft unterstützt zwei Sprachen: Typescript, eine ziemlich neue, typisierte, zu Javascript kompilierbare Sprache, sowie C#. Ich entscheide mich für C#, denn nur so habe ich direkten Zugriff auf äußerst komfortable Spracherweiterungen wie Linq [14], Delegates [15], implizit typisierte Variablen und natürlich die Klassen des Dotnet-Framework.

Bereits das an sich einfache Starten eines neuen Projekts gerät allerdings zur Odyssee. Visual Studio Code erzeugt in seinem jetzigen Reifestadium weder Projekte, noch bringt es einen Webserver mit, der diese ausführt. Also befolge ich brav die Anweisungen unter [16] und installiere den Dotnet Version Manager (»dnvm« , [17]), mit dem ich ein weiteres Werkzeug namens Dotnet Execution Environment (»dnx« , [18]) herunterlade.

Mit einem dritten Tool, dem Node.js-Paketmanager »npm« , kann ich schließlich das eigentliche Programm namens Jeoman [19] aus dem Netz ziehen. Es ist eine Art von Generator für Projektgeneratoren und in der Lage, neue ASP-Net-5-Projekte zu erzeugen.

Weil es Schwierigkeiten mit dem Upgrade von »npm« auf eine neuere als die von Ubuntu mitgelieferte Version gab, entschloss ich mich, mit der Windows-Version von Visual Studio 2013 ein ASP-Net-MVC5-Projekt zu erstellen. Das klappte reibungslos mit wenigen Mausklicks, allerdings tauchten beim Laden dieses Projekts weitere Probleme auf: Omnisharp verweigerte kommentarlos seine Arbeit. Das Log blieb leer und die Intellisense-Funktionen fehlte. Auch hier zeigt sich einmal mehr das Betastadium der Software.

Sehr gut funktionierte bereits der Editor für HTML, CSS und Javascript. Intellisense sowie einige Komfortfunktionen wie die Anzeige von Farben im Stylesheet gibt es schon. Was mir auch hier wieder fehlte, war ein grafischer Editor oder zumindest eine Echtzeitvorschau, um dem Designer die Arbeit zu erleichtern.

Schließlich versuchte ich mich als Letztes an der Debug-Funktionalität. Ist es möglich, die Webseite innerhalb von VSC zu debuggen? Beim Start des Debuggers stellte sich heraus, dass der nur Typescript und Javascript unterstützt, was es unmöglich machte, meine C#-Anwendung zu entlausen.

Fazit

Das Konzept, mit dem Visual Studio unter Windows und Eclipse im Java-Umfeld immer sehr erfolgreich waren, beruht auf der Idee, innerhalb einer integrierten, gut abgestimmten IDE alle nötigen Arbeitsschritte zu vereinen. Da das Programmieren für viele Menschen eine große konzeptionelle Lernhürde darstellt, ist es angenehm, dies zumindest innerhalb eines geschlossenen Ökosystems zu tun, in dem sich Projekte erstellen, ändern, testen und ausliefern lassen.

Hier liegt die momentane Schwäche von VSC: Es fehlen grundlegende Funktionen, nicht nur im Vergleich zur Windows-Version, sondern auch mit anderen IDEs. Dass ich diverse Programme von Drittanbietern nutzen muss, um etwa Projekte zu erzeugen, leuchtet nicht ein.

Auch fehlt mir ein integrierter Webserver, ich musste das Mono-Framework separat herunterladen, was die ersten Entwicklungsschritte mühselig macht. Es verwundert zudem, dass das VSC-Debugging nur Javascript und Typescript, nicht aber C# unterstützt. An dieser Stelle hätte ich erwartet, dass Microsoft die hauseigene Programmiersprache prominenter ausstattet.

So bleibt am Ende nur der Rat, erst einmal die Entwicklungen der Zukunft abzuwarten. Visual Studio Code befindet sich noch in der Preview-Phase. Es bliebe also Zeit, die einzelnen Programmteile besser zu integrieren.

Der Autor

Michael Kißling ist zertifizierter Microsoft-Entwickler und arbeitet seit zehn Jahren als Trainer und Programmierer im Dotnet- und Java-Umfeld. Gelegentlich verschlägt es ihn in die Linux-Welt, in der er LAMP-Webserver und ein Heimkino betreibt.