Über den Strategiewechsel bei Microsoft

Inhaltsverzeichnis

Holger Schwichtenberg sprach für heise Developer mit vier Repräsentanten von Microsoft über den eingeleiteten Strategiewechsel hinsichtlich der verkürzten Veröffentlichungszyklen, der Modularisierung von .NET und der zunehmenden Wichtigkeit von JavaScript.

heise Developer: Microsoft hat angekündigt, die Veröffentlichungszyklen stark zu verkürzen. Wie oft wird also das .NET Framework in Zukunft aktualisiert werden?

Andrew Pardoe: Ja, wir werden die Veröffentlichungszyklen verkürzen, aber wir geben keine konkreten Zyklen bekannt. Projekte auf NuGet veröffentlichen wir ständig. Für Visual Studio gibt es hingegen einen definierten, quartalsweisen Aktualisierungsplan. Microsoft ist aber insgesamt seit einiger Zeit eher verschlossen, was Pläne und Termine angeht.

.NET wird auch zukünftig auf jeder wichtigen Microsoft-Plattform zu finden sein. Wir bemühen uns, .NET im Zusammenspiel mit diesen Plattformen zu veröffentlichen. NuGet ermöglicht uns sogenannte "Out-of-band"-Veröffentlichungen, mit denen wir auch nachträglich Innovationen auf eine Plattform bringen können.

Wir hatten in der Vergangenheit einen Veröffentlichungszyklus für .NET, der vorsah, dass wir eine neue .NET-Version mit jeder neuen Version von Windows und Visual Studio veröffentlichen. Diesen festen Zyklus gibt es jetzt nicht mehr.

Immo Landwerth: Wir werden in den nächsten fünf bis zehn Jahren sehen, dass das .NET Framework nicht mehr größer wird. Weitere Bibliotheken werden wir bei NuGet veröffentlichen. Der Entwickler kann selbst entscheiden, was er verwenden will. Das ist gerade bei Windows Phone wichtig. Er kann entscheiden, ob er die Version einer Bibliothek von gestern Nacht oder eine sechs Monate alte Bibliothek einsetzen will. Somit können wir den Entwicklungslebens- vom Support-Lebenszyklus entkoppeln.

heise Developer: Diese Entwicklung haben wir ja schon beim Entity Framework gesehen. Wird das mit anderen zentralen .NET-Bibliotheken wie WPF (Windows Presentation Foundation) ebenfalls passieren? Werden diese auch vom .NET Framework getrennt und einen eigenen Veröffentlichungszyklus erhalten?

Pardoe: Einige Dinge sind enger mit der Plattform verbunden als andere. Die Klassen im Namensraum System.Net sind ein gutes Beispiel: Die Implementierung variiert stark von Plattform zu Plattform, weil sie so eng mit der jeweiligen Netzwerkschicht verbunden ist. Das gilt auch für WPF und den Silverlight-UI-Stack für Windows Phone. Das sind mehr Investitionen in die Plattform als Investitionen in .NET. Wenn es möglich wäre, diese zu entkoppeln, dann – das kann ich für das .NET-Team sagen – würden wir lieber alles entkoppeln können. So wie wir auch eine neue 64-Bit-Version des Just-in-Timer-Compilers "out of band" veröffentlicht haben. Es ist schöner, etwas zu veröffentlichen, wenn es bereit ist, statt es herauszugeben, wenn die Plattform bereit ist.

Es gab früher ein .NET, das für alle Bedürfnisse passte. Das ist jetzt nicht mehr so. Es gibt viele beschränkte Plattformen – beschränkt hinsichtlich der Größe des Geräts, aber auch beschränkt hinsichtlich der verfügbaren APIs.

Landwerth: In der Vergangenheit konnte man sagen: Wenn du eine einfache API willst, dann ist es eine .NET-API. Wenn du eine API direkt von der Plattform willst, ist das zwar nativ, aber schwer anzuwenden. Wir haben in Windows 8 viel darin investiert, für native APIs die gleiche Usability wie für .NET-APIs zu schaffen. Wir müssen also keine .NET-Wrapper mehr für die Plattform schreiben, nachdem sie erschienen ist. Sie stellt alles direkt und sofort bereit. Für Windows-8-Apps gibt es keinen Managed-UI-Stack. Der ganze UI-Stack kommt direkt von Windows. Und diesen Stack haben die gleichen Leute geschrieben, die auch den für den Desktop und Silverlight geschrieben haben. Die Erfahrungen sind also in Windows 8 eingeflossen.

Die Vorteile von NuGet

heise Developer: Glauben Sie nicht, dass die Entkopplung dann ganz neue Herausforderungen hinsichtlich der Kompatibilität der verschiedenen Bibliotheken und Produkte mit sich bringt? Viele .NET-Entwickler bevorzugten bisher .NET gegenüber Java, weil Microsoft im .NET Framework Redistributable ein großes Paket von Bibliotheken lieferte, in dem die wichtigsten Sachen enthalten waren, während man bei Java erst mal die große Qual der Wahl hat.

Landwerth: Die Auswahl unterstützen wir mit dem neuen "Microsoft & .NET"-Feed in NuGet. Während in NuGet allgemein mehr als 20.000 Pakete enthalten sind, sind es bei "Microsoft & .NET" aktuell nur rund 60. Natürlich wird die Anzahl wachsen, vielleicht auf ein paar Hundert. Diese Pakete unterstützen wir offiziell.

Aber diese Vorauswahl wird wahrscheinlich noch nicht reichen. Entwickler mögen es, ein ganzheitliches Paket zu bekommen, bei dem alles zusammenpasst und unterstützt wird. Das macht das ASP.NET-Team heute schon: Es schnürt die Einzelpakete zusammen und liefert sie mit den Visual-Studio-Updates aus.

In der Zukunft wird es bei uns wohl ähnlich wie bei der Open-Source-Industrie laufen: Damit die Entwickler nicht einzelne Pakete zusammensuchen und dafür sorgen müssen, dass sie zusammenarbeiten, gibt es Firmen, die diese Arbeit erledigen, dem Ganzen einen Namen und eine Versionsnummer geben sowie Support dafür anbieten.

So ähnlich werden wir das auch machen müssen. Wir haben viele Einzelpakete, aber irgendwann werden wir uns sagen: Nun machen wir ein .NET, das wir aus NuGet-Paketen zusammenstellen, die wir zusammen testen und zertifizieren. Die Entwickler können sich dann darauf verlassen, dass Kompatibilität und Performanz stimmen. Und wir geben zehn Jahre Support darauf. Das ist aber im Moment noch fern am Horizont.

Dokumentation: mal schlecht, mal gut

heise Developer: Es gibt aus meiner Sicht inzwischen einige Schwächen bei der Dokumentation. Früher war alles in MSDN dokumentiert. Nun haben einige dieser NuGet-Pakete ihre Dokumentation irgendwo anders. Manche sind sogar nur durch ein paar lose Blog-Einträge dokumentiert.

Landwerth: Grundsätzlich hat die MSDN-Dokumentation ein Problem mit den Unterschieden zwischen verschiedenen Plattformen. Das Ganze ist mit einem Dokumentationssatz gestartet, weil das .NET Framework nur ein großes Ding war. Wenn man bei unserer Immutable-Collections-Bibliothek die Hilfetaste F1 in Visual Studio drückt, landet man in der MSDN-Dokumentation. Das MSDN-Dokumentationsteam aktualisiert alle drei Wochen; wir können also relativ schnell die Dokumentation aktualisieren, wenn wir einen Bug finden.

heise Developer: Aber das ist nicht so gut mit allen Bibliotheken. Ich selbst habe einmal lange nach der Dokumentation der Beta-Version von Entity Framework 6.0 gesucht, aber nichts anderes gefunden als veraltete Spezifikationsdokumente, die auch nicht gut geeignet waren zum Erlernen der Neuerungen.

Landwerth: Ja, das ist der Grund, warum wir eng mit allen Teams im .NET-Bereich zusammenarbeiten. Verschiedene Teams haben verschiedene Vorgehensweisen. Einige Teams legen ihren Schwerpunkt auf häufige Optimierungen und opfern dafür andere Dinge wie die Dokumentation. Die Dokumentationsautoren rennen oft den ständigen API-Änderungen hinterher. Wir selbst hatten die Immutable-Collections-Bibliothek acht Monate als Beta-Version draußen ohne irgendeine Dokumentation; diese kam erst mit dem stabilen Release. Da ist immer eine gewisse Zeitverzögerung, um kosteneffizient zu sein. Wir müssen häufig entscheiden, ob wir Funktionalität oder Dokumentation wollen. Ich würde immer Ersteres wählen, und es gibt ja zumindest die IntelliSense-Unterstützung mit Tooltipps in Visual Studio als Hilfe.

Michael Epprecht: Es hängt vom Team ab. Ein Team, das sehr zeitnah dokumentiert, obwohl sie bei NuGet verbreiten, ist das Azure-Team.

Pardoe: Es kommt auf die Zielgruppe an. Kunden, die Azure nutzen, sind Großunternehmen, die eine Dokumentation zwingend brauchen. Viele, die Apps schreiben, interessiert Dokumentation nicht. Sie wollen den Code und einen Blog-Eintrag.

heise Developer: Es gibt aber außer diesen und den Großunternehmen noch eine Menge anderer Kunden.

Landwerth: Die schwierige Entscheidung ist, wann eine Bibliothek gut genug ist, um sie zu veröffentlichen. Wir wollen ja den Kunden die Möglichkeit bieten, uns Feedback zu geben. Mit vielen Beta-Programmen haben wir das Problem, dass wir 98 Prozent, vielleicht sogar 99 Prozent der Kundenwünsche zurückweisen müssen, weil wir nur noch Zeit haben, Fehler zu beheben. Es ist zu spät, dass Design des Produkts zu ändern.

Bei frühen Veröffentlichungen über NuGet haben wir aber die Möglichkeiten, auch das Design noch einmal zu ändern. Wir können Namensräume tauschen, Typen umbenennen oder auch das Design komplett ändern.

Ich stimme Ihnen zu, dass wir Kompromisse machen müssen. Unser Kernziel ist es, mit einem Produkt so früh wie möglich auf den Markt zu gehen. Das geht aber nicht, ohne gewisse Kompromisse bei Dokumentation und Support zu machen.

Pardoe: Als der neue JIT-Compiler heraus kam, gab es als Dokumentation nur, dass man einen Registry-Key setzen soll und den .NET-Blog lesen soll. Sonst nichts. Kunden, die Fragen hatten, haben den Chefentwickler angeschrieben, und der hat geantwortet. Ist dieses Produkt schon für eine Firma wie Siemens geeignet? Sicherlich nicht. Aber wenn wir den neuen JIT-Compiler irgendwann mit dem .NET Framework ausliefern, wird er dokumentiert sein. In jeder von uns unterstützten Sprache.

.NET

Inkonsistenz bei der Versionierung

heise Developer: Sie liefern .NET 4.5 und .NET 4.5.1 als In-Place-Update aus statt als "Side-by-Side"-Installation wie in der Vergangenheit. Es ist sicherlich nicht "Best Practice", die Versionsnummer einer Assembly nicht zu ändern, wenn sich der Inhalt geändert hat.

Landwerth: "Side-by-Side" ist toll, aber es wirft auch Probleme auf. Vor fünf oder sechs Jahren hat jeder gesagt, Festplattenplatz ist kein Problem. Das ist heute nicht mehr unbedingt wahr. Wenn man sich moderne Geräte ansieht, dann ist der Speicherplatz dort begrenzt. "Side-by-Side" ergibt nur Sinn auf dem PC. Auf Smartphones und in der Cloud macht dieses Prinzip keinen Sinn. Wir denken, dass wir mit dem In-Place-Update für .NET 4.5 und 4.5.1 die richtige Entscheidung getroffen haben. Natürlich gibt es Herausforderungen hinsichtlich Verhaltensänderungen. Wir haben uns extrem bemüht, kompatibel zu bleiben. Wo das nicht möglich oder sinnvoll war, haben wir Schalter eingebaut, mit denen der Entwickler zwischen altem und neuem Verhalten wählen kann.

Grundsätzlich ist unser Ziel, Bibliotheken mit der einzelnen Anwendung auszuliefern. So kann der Entwickler für jede Anwendung selbst entscheiden, wovon sie abhängig sein soll. In einer Firma kann man grundsätzliche Entscheidungen treffen, dass man im Allgemeinen eine Bibliothek in einer bestimmten Version verwendet, aber Ausnahmen für einzelne Anwendungen machen.

heise Developer: Ist denn der Festplattenplatz das einzige Argument für ein In-Place-Update des .NET Framework?

Pardoe: Festplattenplatz ist sicherlich das Schlüsselargument für ein In-Place-Update. In Windows 8 kann man .NET 3.5 nur bei Bedarf installieren. Mit .NET 4.0 gab es fundamentale Änderungen. Das wäre kein Fall für ein In-Place-Update gewesen. Wenn wir aber Kompatibilität garantieren können, dann werden wir ein In-Place-Update machen. Das ist einfacher als so viele CLR-Versionen auf einem Rechner zu haben. Und wenn man sich Plattformen wie Windows Store, Windows Phone und Xbox ansieht, dann gibt es da kein .NET Redistributable. Die Plattform selbst umfasst eine bestimmte .NET-Version.

Epprecht: Man muss bei dieser Frage auch den Support einbeziehen. Wenn man vier verschiedene Versionen einer Software auf einem Rechner hat, muss man einen Bug gegebenenfalls in allen vier Versionen beheben, also vier verschiedene Updates installieren. Das ist eine wichtige Überlegung, insbesondere für große Unternehmen.

heise Developer: Die CLR war in .NET 2.0, 3.0 und 3.5 gleich. In der Vergangenheit hat Microsoft aber wenigstens die einzelnen Assemblies mit verschiedenen Versionsnummern belegt. In .NET 4.5 und 4.5.1 sind auch diese Versionsnummer gleich geblieben.

Landwerth: Wir haben eine Reihe komplizierter Vorgänge in .NET. Dazu gehören neben dem JIT-Compiler und dem Garbage Collector auch die Versionierung. Wir müssen für eine Referenz die richtige Assembly finden. Es ist natürlich alles viel einfacher, wenn die Versionsnummer gleich bleibt. Aber ich gebe Ihnen Recht, dass wir beim .NET Framework nicht die gleichen Versionierungsrichtlinien verwenden, die wir Kunden bei der Anwendungsentwicklung empfehlen. Zu berücksichtigen ist auch, dass nicht alle .NET-Plattformen die gleiche Versionsstrategie verwenden. Für Windows-Phone-8- und Windows-Store-Anwendungen wird eine Assembly mit einer höheren als die erwartete Versionsnummer geladen, während auf dem PC genau die richtige Versionsnummer erwartet wird. Da muss man in der app.config einen Binding Redirect eintragen, damit das läuft. Grundsätzlich aber erhöhen wir immer die Versionsnummer nach den Prinzipien des Semantic Versioning.

Status quo .NET

heise Developer: Viele Entwickler haben das Gefühl, dass Microsoft sich nicht mehr genug um das .NET Framework bemüht, sondern sich mehr um andere Plattformen kümmert. Einige Features in Visual Studio 2013 gibt es nur für Windows-Store-Apps.

Pardoe: Microsoft war immer auf Großunternehmen fokussiert, zumindest solange Steve Balmer das Schiff gesteuert hat. Mit Windows 8 und Windows Phone haben wir uns entschlossen, einen neuen Fokus auf Konsumenten zu haben. Die Mobilgeräte, die wir davor hatten, Windows-Mobile-Telefone und Windows-XP-Tablets, hatten viele Features für Großunternehmen, aber ich hätte die nie in die Hand meiner Mutter gelegt. Wir betreten also nun einen neuen Markt. Also haben wir auch viel Marketing für die Möglichkeiten gemacht, Windows-Apps mit C++ und HTML5/JavaScript zu programmieren, damit wir die Entwickler dazu bewegen, für Windows zu programmieren. Die .NET-Entwickler sind ja eh schon auf der Windows-Seite. Wenn man sich den Windows Store ansieht – ich weiß keine genauen Zahlen –, ist es offensichtlich, dass die meisten Apps mit .NET entwickelt sind.

heise Developer: Ich denke aber, dass beantwortet nicht die Frage, warum wir in Visual Studio 2013 Features sehen, die es nur für die App-Programmierung gibt, nicht aber für klassische .NET-Anwendungen.

Landwerth: Microsoft ist eine große Firma, bei der der Fokus mal auf der einen, mal auf der anderen Sache liegt. Sie werden feststellen, dass vor allem über die Features in Visual Studio gesprochen wird, die unser Marketing treibt. Aber Sie werden auch feststellen, dass es alle Out-of-Band-Bibliotheken für .NET auch für Windows Store, Windows Phone, Silverlight und Windows Desktop gibt.

heise Developer: Einige Entwickler haben Angst, dass .NET aufs Abstellgleis geschoben wird. Werden wir denn sicher in Zukunft neue Versionen von .NET sehen?

Pardoe: Auf jeden Fall!

Steve Fox: Microsoft sagt nicht, dass alle HTML5 und JavaScript machen müssen. Wir haben unseren Kunden zugehört. Wir wollen den Entwicklern Optionen geben. Es ist heute nicht mehr so, dass Microsoft der Industrie sagt, was zu tun ist. Es gibt heute Cross-Plattform-Strategien in Unternehmen.

Investitionen, Altlasten

heise Developer: Kunden vermissen aber Investitionen in den klassischen Desktop, zum Beispiel WPF.

Fox: Fakt ist, dass wir nicht alles gleichzeitig machen können. Wir fokussieren uns auf eine Sache, machen es richtig, und dann legen wir den Fokus auf eine andere Sache.

Epprecht: Vergessen Sie nicht, dass Microsoft zehn Jahre Support gibt. Also erst 2022 wird der Support für .NET 4.5 auslaufen.

heise Developer: Zehn Jahre Support für den Bestand reicht den Entwicklern aber nicht. Sie wollen auch neue Features und Tools sehen.

Landwerth: Ja, ich war auch Kunde, bis ich vor drei Jahren zu Microsoft ging. Eines ist klar: Man kann nicht alle Windows-Anwendungen in Apps konvertieren. Visual Studio als App? Das macht keinen Sinn. Diese Dinge wird es also weiter geben. Es gibt bei WPF noch Dinge, die fehlen. Aber das Delta ist viel geringer als das, was an anderen Stellen noch fehlt.

Man muss bedenken, dass .NET schon ein mächtiges Produkt ist. Innovationen werden da immer schwieriger. Die Latte für die Einführung neuer APIs im Kern von .NET hängt extrem hoch, denn wir müssen an Milliarden von Computern mit .NET denken. Alles was wir für den Desktop tun, ist daher sehr teuer. Das ist der Grund, warum Sie weniger Momentum dort sehen.

Pardoe: Wir haben die Anweisung von unserem Management, dass wir verstehen sollen, was unsere Kunden verwenden. Wir müssen dies in alle Entscheidungen einbeziehen, sodass wir Innovationen in dem für den Kunden relevanten Bereichen liefern. Wir wissen zum Beispiel, dass viele Kunden für viele Geschäftsanwendungen WPF im Einsatz haben und dass Großkunden Silverlight in deren Intranets nutzen. Wir werden dies definitiv bei unseren Investitionsentscheidungen berücksichtigen.

heise Developer: Ich treffe immer wieder Leute, die denken, Microsoft ist doch eine so große Firma. Die können doch HTML5/JavaScript und .NET sowie Silverlight gleichermaßen und am besten auch Visual Basic 6 vorantreiben.

Pardoe: Microsoft hat aber nicht hunderttausend Entwickler. Das sind meist kleine Teams. Im JIT-Compiler-Team sind es nur 12 Entwickler und Tester, und die haben geraden den neuen
64-Bit-Compiler für .NET entwickelt!

heise Developer: Vielen Dank für das Interview.

Das Interview führte Dr. Holger Schwichtenberg (www.IT-Visions.de). (ane)