Überblick über die Neuerungen im .NET Framework 1.1 und Visual Studio .NET 2003

Veröffentlicht: 05. Mrz 2003 | Aktualisiert: 23. Jun 2004

Von Christian Weyer

Die als "Everett" bekannt gewordene neue Version von Visual Studio .NET steht kurz vor der offiziellen Vorstellung. Zusammen mit dem .NET Framework 1.1 ist es die aktuelle Entwicklungsplattform und -umgebung für den .NET-Programmierer. In diesem Artikel möchte ich vor allem auf die Neuerungen eingehen, die den ASP.NET-Programmierer betreffen. Um es vorweg zu nehmen: es handelt sich um eine sanfte Evolution, vieles wird besser, aber nichts wirklich Neues ist in Sicht.

Auf dieser Seite

 Alle miteinander: Side-by-Side in der Praxis
 XML Web Services: Gepflegt und gehegt
 Unterwegs mit .NET: Mobile Anwendungsentwicklung integriert
 Sicherheit: Sicherer gemacht
 ISP Hosting: Endlich sinnvoll möglich
 Besser, nicht neuer

Sind wir doch mal ehrlich: Für eine Version 1.0 (was Visual Studio .NET 2002 ja eigentlich ist) macht die Entwicklungs- und die Laufzeitumgebung von .NET schon einen recht stabilen, zuverlässigen und insgesamt guten Eindruck. Doch es gibt nichts auf dieser Welt, was man nicht verbessern könnte, so auch das .NET Framework mitsamt IDE. Also wird Microsoft in Kürze das .NET Framework 1.1 und Visual Studio .NET 2003 veröffentlichen.

Alle miteinander: Side-by-Side in der Praxis

Von Seiten Microsofts wird die gleichzeitige Installation unterschiedlicher .NET Framework-Versionen in zahlreichen Präsentationen und Artikeln als heraus ragendes Merkmal der Stärke von .NET gepriesen. Und mit dem Erscheinen von Framework Version 1.1 wird dies noch mal verstärkt betont.

Dabei kennen viele Entwickler diese Fähigkeit bereits aus dem alltäglichen Leben. Die Beta-Versionen konnten friedlich mit der ersten offiziellen Release-Version nebeneinander auf einer Maschine leben. Mit der neuen Version 1.1 macht die Side-by-Side-Unterstützung nun aber richtig Sinn. Für Programme, die auf Basis von 1.0 geschrieben und nach und nach die neuen Funktionalitäten von 1.1 erhalten sollen, kann der Entwickler beide Frameworks und sogar beide Visual Studio .NET-Versionen nebeneinander auf seinem PC installieren.

Zur Erleichterung einer kontrollierbaren Entwicklung kann man Visual Studio .NET 2003 sogar sagen, für welche Runtime es Code erzeugen soll. Abbildung 1 zeigt die möglichen Szenarien, die bei einer gemischten Umgebung auftreten können.

Szenarien für Side by Side Support

Abbildung 1: Szenarien für Side by Side Support mit mehreren Versionen des .NET Frameworks

Wenn eine Anwendung mit Version 1.0 kompiliert wurde, dann wird versucht, diese Anwendung auf einem System nur mit Framework 1.1 auszuführen. Und zwar solange bis die Anwendung dies explizit verbietet. Sind hingegen beide Frameworks vorhanden, dann läuft die Anwendung solange auf 1.0 bis ein Administrator dies ändert. Im Falle einer Anwendung auf Basis von 1.1 kann diese allerdings nur auf einem System mit .NET Framework 1.0 installiert und ausgeführt werden, wenn der Administrator dies zulässt.

Für ASP.NET bedeutet die Unterstützung mehrerer Versionen, dass man dem Web Server (in den meisten Fällen der IIS) mitteilen muss, welche Version für die Abarbeitung der ASP.NET Ressourcen wie .aspx oder .asmx verantwortlich ist. Dies geschieht am einfachsten über die Management Console des IIS (siehe Abbildung 2). In der Abbildung ist der IIS6 zu sehen. Alternativ kann man diese Bindung natürlich auch wie gewohnt über die jeweiligen Web-Anwendungseinstellungen in der IIS-Konsole vornehmen.

ASP.NET Mapping im IIS6 für Version 1.1 aktiviert

Abbildung 2: ASP.NET Mapping im IIS6 für Version 1.1 aktiviert

 

XML Web Services: Gepflegt und gehegt

Nein, die neuen Spezifikationen des GXA Frameworks und deren Implementierung in den Web Services Enhancements (WSE) sind nicht Bestandteil von .NET Framework 1.1. Das werden sie auch in Zukunft nicht werden. Und zwar aus einem ganz einfachen Grund: der Release-Zyklus von Framework und Visual Studio beträgt ca. 12 Monate (zumindest momentan). Wenn nun aber erst alle 12 Monate neue Versionen für die Unterstützung weiterführender XML Web Services-Funktionalität unter das Volk gebracht wird, können wir die schöne Vision von Web Services wohl bald begraben. Daher werden die WSE ein eigenständiges Produkt bleiben und viel häufiger in neuen Versionen erscheinen (Download hier).

Neben zahlreichen Bug Fixes und kleinen Verbesserungen vor allem bezüglich der Interoperabilität bei SOAP, XSD und WSDL im ASMX-Stack kann man daher im .NET Framework 1.1 keine großartigen Neuerungen im Bereich der XML Web Services finden. Ein großer Schub an zusätzlicher Funktionalität und neuen Features ist erst wieder mit dem nächsten großen Release "Whidbey" zu erwarten (im gleichen Zeitraum wie die neue SQL Server Version, Codename "Yukon").

Jedoch sind einige Kleinigkeiten durchaus erwähnenswert. Aus dem Grund weil sie entweder dem Entwickler das Leben vereinfachen oder ihn verzweifeln lassen können.

Die erste Neuerung fällt einem auf, wenn man sich die dynamisch erzeugte WSDL eines Web Services betrachtet (siehe Abbildung 3). Sie ist nun viel kürzer als in der alten Version. Dies hat den einfachen Grund, dass nun per Default nur die SOAP-Bindung über das WSDL exportiert wird. In Version 1.0 konnte man im WSDL zusätzlich noch eine Bindung für HTTP GET und HTTP POST finden. Dadurch wurde zum einen die WSDL-Repräsentation unnötig aufgebläht und zum anderen sah man bei Microsoft hier ein mögliche Sicherheitslücke welche im Rahmen der Trustworthy Computing-Initiative geschlossen wurde. Selbstverständlich kann man diese Protokolle auch weiterhin durch eine Angabe in der Konfigurationsdatei aktivieren oder wieder deaktivieren.

netframework1_1_03

Abbildung 3: Standardmäßig erzeugtes WSDL mit ASP.NET 1.1

Eng mit diesem Punkt verbunden ist die Tatsache, dass die Testseite eines Web Services nun nur noch auf der lokalen Maschine funktionsfähig ist. Wie in Abbildung 4 zu sehen ist, kann ein Benutzer auf einem entfernten PC zwar diese Seite sehen, aber den Web Service nicht mehr testen. Wir können diesen Umstand auch in die Rubrik "verbesserte Sicherheit in den Standardeinstellungen" abheften. Außerdem wird die Testfunktionalität jetzt nicht mehr über einen GET sondern per HTTP POST aufgerufen. Durch folgendes XML-Fragment (in die web.config eingebettet) lassen sich im Übrigen alle drei verfügbaren Protokollvarianten wieder aktivieren:

<configuration> 
  <system.web> 
 <webServices> 
   <protocols> 
  <add name="HttpGet" /> 
  <add name="HttpPost" /> 
   </protocols> 
 </webServices> 
  </system.web> 
</configuration>

netframework1_1_04

Abbildung 4: Ab Version 1.1 ist die XML Web Services-Testseite nur noch vom lokalen Rechner aus abrufbar (konfigurierbar)

Die letzte kleine aber wirklich feine Änderung ist der Dialog zum Hinzufügen eines so genannten Webverweises. Gemeint sind hiermit Verweise auf einen XML Web Service. Über diesen Dialog wird spezifiziert, welchen Web Service man in seine Anwendung einbauen möchte. Dazu gibt man einfach den Ort der zugehörigen WSDL-Beschreibung an und auf Knopfdruck wird eine clientseitige Proxyklasse entweder in C# oder VB.NET für den gekapselten Zugriff auf den Web Service erzeugt. So weit also nichts Neues.

Aber wer hat sich nicht darüber geärgert, dass sowohl der Name des Webverweises im Visual Studio als auch der Namespace der erzeugten Klasse so heißen wie der Ursprungsserver des Web Service? Im neuen Dialog kann man nun direkt festlegen, welchen .NET Namespace man vergeben möchte (vergleiche Abbildung 5).

In der Abbildung kann man auch sehen, dass nicht mehr das rohe WSDL angezeigt wird. Vielmehr wird unter Einsatz einer XSLT-Transformation eine für den Entwickler besser lesbare Repräsentation der Web Service-Schnittstelle dargeboten. Durch Anzeige des Quelltextes dieser Seite kann man sich aber immer noch das eigentliche WSDL anschauen.

netframework1_1_05

Abbildung 5: Der Dialog zum Hinzufügen eines Web Services-Verweises wurde überarbeitet

 

Unterwegs mit .NET: Mobile Anwendungsentwicklung integriert

Eine der interessantesten Visionen der .NET-Geschichte, die uns Microsoft erzählen möchte, ist sicherlich die Nutzung von Anwendungen und Daten mit mobilen Endgeräten. Dabei gibt es prinzipiell zwei grundlegende Ausprägungen: Web-basierte Anwendungen, welche speziell für z.B. WAP-Handys oder PDAs erstellt wurden. Und echte .NET-Anwendungen mit Windows Forms, die auf mobilen Devices wie Pocket PC oder Smartphone ablaufen können.

Für jede dieser Varianten bietet Visual Studio .NET 2003 nun von Hause aus eine sehr gute Unterstützung. Zur Entwicklung von mobilen Web-Anwendungen wurde das bisher als Mobile Internet Toolkit bekannte Add-On in das .NET Framework integriert. Auch in der IDE gibt es eigene Projektvorgaben speziell für diese Art von Applikation. Wenn man echte .NET-Anwendungen erstellen und auf den PDA installieren möchte, musste man bisher auf die so genannten Smart Device Extensions (SDE) und das .NET Compact Framework als separaten Download zurück greifen. Auch diese sind nun im Paket mit enthalten. Dadurch wird eine nahtlose Anwendungsarchitektur auch auf der Clientseite erheblich erleichtert.

Abbildung 6 zeigt eine Pcoket PC-Anwendung im Pocket PC 2002-Emulator, welche auf einen entfernten XML Web Service zugreift, um deutsche und englische Begriffe online übersetzen zu lassen. Diese Anwendung habe ich in vier (4 !) Minuten "programmiert".

netframework1_1_06

Abbildung 6: .NET Compact Framework und Smart Device Extensions sind integraler Bestandteil von Visual Studio .NET 2003 (hier der Pocket PC 2002 Emulator)

 

Sicherheit: Sicherer gemacht

Wie bereits schon weiter oben angedeutet, steht Sicherheit wirklich ganz oben auf der Liste bei allen Produktgruppen innerhalb von Microsoft. So natürlich auch bei ASP.NET. Die Formular-basierte Authentifizierung in einer ASP.NET-Anwendung (Forms Authentication) ist eine grosse Hilfestellung für die Implementierung einer Login-Seite mit Anbindung an eigene Datenquellen. Allerdings gehen die Logininformationen wie Username und Passwort hier im Klartext über die Leitung! Das ist freilich ein unzumutbarer Zustand.

Abhilfe schaffen kann hier der Einsatz von Secure Sockets Layer (SSL). In Version 1.1 gibt es zusätzlich ein Attribut im Abschnitt Forms der web.config: requireSSL. Wenn man requireSSL auf true setzt, dann wird automatisch HttpCookie.Secure gesetzt, was zur Folge hat, dass das Authentifizierungs-Cookie nur noch dann übertragen wird, wenn die Verbindung zwischen Client und Server tatsächlich durch SSL gesichert ist, ausgehend vom Browser. False ist übrigens der voreingestellte Wert.

Eine interessante Möglichkeit, die ASP.NET-Laufzeitumgebung unter einem anderen Benutzerkonto laufen zu lassen, kann in der machine.config eingestellt werden. Im Gegensatz zu vorherigen Versionen kann man nun das benötigte Passwort auch mit Hilfe einer Kommandozeilenanwendung verschlüsseln. Auch andere Bereiche in machine.config oder web.config, die Benutzername und Passwort verlangen können durch diese Vorgehensweise abgesichert werden. Eine genaue Anleitung mitsamt Download eines kleinesn Hilfswerkzeugs finden Sie in der Microsoft Knowledge Base. Beachten Sie aber bitte, dass Sie mit Nutzung dieses Features keine komfortable XCOPY Deployment-Möglichkeit mehr haben!

Die letzte Änderung im Bereich Sicherheit betrifft das Cross Site Scripting. Darunter versteht man eine Attacke auf eine Web Site durch Injizieren von Script Code in HTML Formulare, die dann serverseitig abgearbeitet werden (mehr Informationen über Cross Site Scripting finden Sie hier.).

Ab Version 1.1 ist nun standardmäßig ein Überprüfungsmechanismus aktiviert, der diese Angriffe verhindern soll. Denn Cross Site Scripting-Attacken können vor allem in ASP.NET sehr häufig verwendeten PostBack auftauchen. Man kann über das Attribut ValidateRequest der @Page-Direktive diese Überprüfung ab- oder wieder einschalten. Die Default-Einstellung wird über einen Eintrag in der machine.config fest gelegt. Sie können auch über einen eigenen Wert in der web.config dieses Standardverhalten pro Web-Anwendung ändern.

 

ISP Hosting: Endlich sinnvoll möglich

Die wohl signifikanteste Neuerung für ASP.NET bringt keine wesentlichen Vorteile für den Entwickler, wohl aber für diejenigen, die ASP.NET hosten wollen. ASP.NET unterstützt jetzt Code Access Security (CAS). Über so genannte Trust Levels lässt sich genau einstellen, was eine einzelne Anwendung darf und was nicht. Dabei gibt es vorgefertigte Trust Levels, man kann aber auch eigene definieren und diese durch einen Eintrag in der web.config einsetzen.

Es soll bald einen Artikel auf MSDN Online USA über Best Practices für Internet Solution Provider in Verbindung mit ASP.NET 1.1 erscheinen. Somit sollte einem breiten Einsatz von ASP.Net in der Öffentlichkeit und im Massenmarkt nichts mehr entgegen stehen.

 

Besser, nicht neuer

Freilich hat meine Auflistung der Neuerungen keinerlei Anspruch auf Vollständigkeit. Zumal selbst die Entwickler bei MS mir keine vollständige Feature/Bug Fix-Liste geben konnten J. Ich bin beispielsweise nicht auf die jeweiligen Neuerungen in den Programmiersprachen, in ADO.NET oder alle kleinen Änderungen in Visual Studio .NET 2003 eingegangen.

Eine wichtige Änderung ist die Möglichkeit der enge Verschmelzung von ASP.NET mit dem neuen Prozessmodell von IIS6. Dies bringt völlig neue ungeahnte Konfigurationsmöglichkeiten und schlägt sich hauptsächlich in sehr hoher Geschwindigkeit nieder.

Diesem Thema gebührt aber ein eigener Artikel. Das Upgrade von 2002 auf 2003 wird übrigens einen kleinen Obolus abverlangen. Der genaue Preis steht aber noch nicht fest, wird aber für jeden Entwickler tragbar sein und die Ausgabe lohnen.