Seite 2: .NET

Inhaltsverzeichnis

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)