Reicht .NET 2.0, oder muss man .NET 3.5 einsetzen?

Werkzeuge  –  Kommentare
Anzeige

Microsoft hat seit 2005 alljährlich eine neue Version des .NET-Frameworks veröffentlicht. Viele .NET-Entwickler, die noch mit der 2005 erschienenen Version 2.0 arbeiten, fragen sich, ob sie weiterhin mit dieser Release arbeiten können oder auf das aktuelle .NET 3.5 Service Pack 1 umstellen sollten oder sogar müssen.

10 wichtige Fragen zu .NET

Das ist der Auftaktartikel einer zehnteiligen Serie, in der .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen liefert, die .NET-Entwickler beschäftigen.

Auf das "müssen" kann man eine eindeutige Antwort geben: nein. Aktuelle und zukünftige Windows-Betriebssysteme unterstützen .NET 2.0 genau so gut wie .NET 3.0 und .NET 3.5. Denn .NET 3.0 und .NET 3.5 stellen echte Obermengen von .NET 2.0 dar. Letzteres ist die Basis für die 3.x-Versionen; die Laufzeitumgebung (CLR (Common Language Runtime)) ist gleich, lediglich der Umfang der .NET-Bibliotheken ist größer geworden. Daher installiert die Setup-Routine von .NET 3.0 und 3.5 zuerst .NET 2.0 und dann die separaten Erweiterungen. Genau genommen installiert man auch Service Packs für .NET 2.0. Es gibt aber nur wenig denkbare Fälle, in denen eine .NET-2.0-Anwendung nicht auf einem Rechner mit installiertem .NET 3.x läuft. Das ist der Fall, wenn Nebenwirkungen von Bugfixes zum Tragen kommen.

Auch in Visual Studio 2008 und dem kommenden Visual Studio 2010 ist Unterstützung für .NET 2.0 vorhanden. Durch die "Multi-Targeting" genannte Funktion kann der Entwickler (schon beim Anlegen eines Projekts oder auch später noch) auswählen, ob Visual Studio nur die Möglichkeiten von .NET 2.0 anbieten soll oder aber .NET 3.0 beziehungsweise 3.5. Leider unterscheidet Microsoft nicht zwischen .NET 3.5 und .NET 3.5 Service Pack 1, obwohl das Service Pack so viele neue Funktionen bietet, dass eine Differenzierung sinnvoll wäre. Schwierigkeiten können auftreten, wenn man in Visual Studio 2008/2010 im .NET-2.0-Modus entwickelt und Funktionen aufruft, die erst in den automatisch mit .NET 3.x installierten Service Packs von .NET 2.0 hinzugekommen sind. Die so kompilierten Anwendungen würden dann nicht auf einem System ohne Service Pack einwandfrei funktionieren. Leider gibt es weder in Visual Studio noch beim Start einer solchen Anwendung eine Warnung. Das Problem tritt erst beim "Betreten" einer Unterroutine auf, die eine dieser neuen Funktionen verwendet. Zumindest gibt es für Visual Studio Team System (VSTS) und den eigenständigen Code-Polizisten FxCop eine separate Erweiterung, mit der Programmierer zur Entwicklungszeit Aufrufe der neuen Funktionen erkennen können.

Es bleibt die Frage, ob man auf .NET 3.x umstellen sollte. Für .NET 3.0 war diese Frage für viele Entwickler einfach zu beantworten, denn sie brauchten weder die verbesserte Unterstützung für verteilte Systeme in der Windows Communication Foundation (WCF) noch die für typische Geschäftsanwendungen unreife Windows Presentation Foundation (WPF) und schon gar nicht die kaum zu gebrauchende Windows Workflow Foundation (WF) oder das Nischen-Authentifizierungsprodukt Windows CardSpace (WCS). Die etwa zum gleichen Zeitpunkt erschienenen AJAX-Erweiterungen für ASP.NET gibt es auch als separate Erweiterung für .NET 2.0. WCF und WPF waren nicht wertlos, aber nur für einen kleineren Teil der .NET-Entwickler interessant. Für viele Programmierer, die mit verteilten Systemen oder mit Sicherheitsfunktionen ausgestatteten Webservices arbeiten, war WCF ein großer Schritt nach vorn. WPF ist auf jeden Fall dann wichtig, wenn es um aufwendige grafische Anwendungen geht oder um animationsreiche Benutzeroberflächen für Konsumenten-Software.

Beim .NET Framework 3.5 fällt es fast jedem Entwickler schwer, "Nein" zu sagen: Die zahlreichen Spracherweiterungen für C# und Visual Basic, insbesondere die in die Sprachen integrierte, universelle Suchsprache LINQ, machen .NET 3.5 für jede Art von Anwendungen attraktiv. Wer bisher noch Datenzugriff mit händischem SQL oder klobigen typisierten Datasets erstellte, sollte sich das objektrelationale Mapping (ORM) mit LINQ-to-SQL und dem ADO.NET Entity Framework ansehen. Wer freilich bisher schon einen .NET-ORM eines Drittanbieters wie nHibernate, .NET Data Objects, Genome, Wilson ORM, eXpress Persistent Objects oder Telerik Open Access verwendet, hat von Microsofts ORM-Werkzeugen wenig bis keinen Zugewinn. ASP.NET hat in .NET 3.5 Service Pack 1 einige wesentliche Produktivitätsüberarbeitungen erfahren, insbesondere die dynamischen Daten-Websites. Bei der Kommunikation mit WCF 3.5 sind die Unterstützung für RSS und Atom sowie die ADO.NET Data Services erwähnenswert. WPF ist durch .NET 3.5 reifer geworden. Nur die Workflow-Implementierung kann man weiterhin ruhig links liegen lassen, denn hier wird in .NET 4.0 alles anders.

Anzeige