Über den Strategiewechsel bei Microsoft

heise Developer im Gespräch mit vier Microsoft-Repräsentanten über den eingeleiteten Strategiewechsel hinsichtlich der verkürzten Veröffentlichungszyklen, der Modularisierung von .NET und der zunehmenden Wichtigkeit von JavaScript.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Lesezeit: 18 Min.
Von
  • Alexander Neumann
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, Program Manager für die Common Language Runtime

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, Program Manager im .NET-Framework-Kernteam

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.

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.

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, Solution Architect für Microsoft Azure Modern Apps

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.