(0) exportieren Drucken
Alle erweitern

Webserver in Visual Web Developer

Aktualisiert: November 2007

Dieses Thema beschreibt, wie Sie zum Testen und Ausführen von Websites entweder Internetinformationsdienste (IIS) oder den integrierten ASP.NET Development Server verwenden.

Um ASP.NET-Webanwendungen zu testen oder auszuführen, benötigen Sie einen Webserver. Der Produktionswebserver für Microsoft-Betriebssysteme ist IIS. Zu IIS zählen ein Webserver, ein FTP (File Transfer Protocol)-Server, ein virtueller SMTP (Simple Mail Transfer Protocol)-E-Mail-Server und weitere Funktionen. Zum Ausführen von IIS müssen Sie mit einer Windows-Version arbeiten, die als Server in einer Netzwerkumgebung eingesetzt werden kann. Dies ist zum Beispiel die Web Edition von Windows Server 2003.

In Windows 2000 Server und in früheren Versionen der Windows Server-Betriebssysteme ist IIS standardmäßig als Teil des Betriebssystems installiert. In Windows XP und Windows Server 2003 ist IIS nicht standardmäßig installiert. Sie können IIS in der Systemsteuerung unter Software mit der Option Windows-Komponenten hinzufügen/entfernen hinzufügen. (In Windows Server 2003 können Sie IIS mithilfe der Anwendungsserverkomponente installieren.)

In den folgenden Fällen ist die Arbeit mit IIS eher unpraktisch:

  • Sie entwickeln ASP.NET-Webseiten und arbeiten dabei mit Windows XP Home Edition, die IIS nicht unterstützt.

  • Sie möchten aus Sicherheitsgründen keinen Webserver auf Ihrem Computer hosten (z. B. auf Ihrem Heimnetzwerk). Das Ausführen eines Webservers wie IIS erfordert zusätzliche Maßnahmen zur Sicherung des Servers. Dazu gehört das regelmäßige Installieren der aktuellen Sicherheitsupdates.

  • Aufgrund von Firmenrichtlinien können Sie bestimmte Serverkomponenten, z. B. IIS, nicht installieren.

Wenn Sie IIS nicht als Webserver verwenden können oder möchten, können Sie die ASP.NET-Seiten immer noch mit dem ASP.NET Development Server testen. Der in Visual Web Developer enthaltene ASP.NET Development Server ist ein Webserver, der lokal auf Windows-Betriebssystemen (einschließlich Windows XP Home Edition) ausgeführt wird. Dieser Server wurde speziell dafür entwickelt, ASP.NET-Webseiten auf einem lokalen Host (Suche und Webserver werden auf dem gleichen Computer ausgeführt) zu übermitteln oder auszuführen. Mit anderen Worten: ASP.NET Development Server übermittelt Seiten an Browseranforderungen auf dem lokalen Computer. An andere Computer werden keine Seiten übermittelt. Außerdem werden keine Dateien übermittelt, die sich außerhalb des Gültigkeitsbereichs der Anwendung befinden. ASP.NET Development Server stellt eine effiziente Möglichkeit dar, Seiten lokal zu testen, bevor die Seiten auf einem Produktionsserver mit IIS ausgeführt werden.

ASP.NET Development Server akzeptiert nur authentifizierte Anforderungen auf dem lokalen Computer. Dafür muss der Server NTLM oder die Standardauthentifizierung unterstützen.

58wxa9w5.alert_note(de-de,VS.90).gifHinweis:

Es hat sich bewährt, Visual Web Developer nicht auszuführen, wenn Sie als Administrator angemeldet sind. Verwenden Sie stattdessen ein eingeschränkteres Konto. Dadurch wird der unbeabsichtigte Zugriff auf andere Dateien auf dem Server vermieden.

ASP.NET Development Server funktioniert nur mit einzelnen Seiten und schließt keine IIS-Extrafunktionen ein. So unterstützt ASP.NET Development Server z. B. keinen SMTP-E-Mail-Server. Wenn Sie für die Webanwendung auf das Senden von E-Mail-Nachrichten angewiesen sind, müssen Sie zum Testen der E-Mail-Funktion Zugriff auf den virtuellen SMPT-Server von IIS haben, da ASP.NET Development Server weder selbst E-Mail-Nachrichten weiterleiten noch einen anderen Server damit beauftragen kann.

Ausführen des ASP.NET Development Servers

ASP.NET Development Server wird standardmäßig zusammen mit Visual Web Developer installiert. Wenn Sie mit einer Dateisystem-Website arbeiten, verwendet Visual Web Developer zum Ausführen von Seiten automatisch den ASP.NET Development Server. In einem lokalen Hostszenario wird der Webserver standardmäßig an einem zufällig gewählten Anschluss aufgerufen. Wenn Sie z. B. eine Seite mit dem Namen ExamplePage.aspx testen und die Seite auf dem ASP.NET Development Server ausgeführt wird, könnte die URL der Seite folgendermaßen aussehen:

http://localhost:31544/ExamplePage.aspx

Wenn Sie den Browser schließen, wird ASP.NET Development Server wieder beendet.

Wenn Sie den ASP.NET Development Server an einem bestimmten Anschluss ausführen möchten, können Sie den Server dafür konfigurieren. Dies bietet sich in folgenden Szenarios an:

  • Wenn der Code der Anwendung einen bestimmten Anschluss überwacht und Sie die Anwendung mit dem ASP.NET Development Server testen möchten.

  • Wenn die Anwendung einen Verweis auf ein Clientprojekt oder einen Webdienst enthält, das bzw.der an einen bestimmten Anschluss gebunden ist.

Visual Web Developer kann nicht garantieren, dass der angegebene Anschluss zu dem Zeitpunkt verfügbar ist, an dem Sie Ihre Dateisystem-Website ausführen. Ausführliche Informationen finden Sie unter Gewusst wie: Angeben eines Anschlusses für den ASP.NET Development Server.

Sicherheitskontext für den ASP.NET Development Server

Ein wesentlicher Unterschied zwischen dem ASP.NET Development Server und IIS ist der Sicherheitskontext, in dem der jeweilige Server die ASP.NET-Seiten ausführt. Dieser Unterschied kann Auswirkungen auf das Testen der Seiten haben, da die Seiten unterschiedlich ausgeführt werden.

Wenn Sie eine Seite mit dem ASP.NET Developement Server ausführen, wird die Seite im Kontext des aktuellen Benutzerkontos ausgeführt. Wenn Sie z. B. eine Seite als Administrator ausführen, verfügt eine auf dem ASP.NET Development Server ausgeführte Seite über Rechte auf Administratorebene. Bei IIS wird im Gegensatz dazu ASP.NET standardmäßig im Kontext eines speziellen Benutzerkontos (ASPNET oder NETZWERKDIENSTE) ausgeführt, das in der Regel über eingeschränkte Rechte verfügt. Die Benutzerkonten ASPNET oder NETZWERKDIENSTE befinden sich lokal auf dem Servercomputer (keine Domänenkonten), wodurch der Zugriff auf Ressourcen auf anderen Computern beschränkt ist.

Wenn Sie den Code in ASP.NET-Seiten einfach nur lesen und ausführen, spielt dieser Unterscheid keine große Rolle. Jedoch kann der unterschiedliche Sicherheitskontext für die beiden Webserver das Testen folgendermaßen beeinflussen:

  • Zugriff auf andere Ressourcen, die von der Seite benötigt werden   Dazu gehört beispielsweise das Lesen und Schreiben von Dateien, die keine Webseiten sind, oder das Lesen und Schreiben der Windows-Registrierung u. a.

  • Datenbankzugriff   Wenn Sie mit ASP.NET Development Server arbeiten, können Sie sich für den Zugriff auf SQL Server in der Regel auf die integrierte Windows-Authentifizierung verlassen. Wenn Sie jedoch die gleiche Seite in IIS unter dem Konto ASPNET oder NETZWERKDIENSTE ausführen, wird die Seite im Kontext eines lokalen Benutzers ausgeführt. Dabei müssen Sie die Seite oft so konfigurieren, dass sie eine Verbindungszeichenfolge verwendet, die Informationen über Benutzer und Kennwort enthält. Ausführliche Informationen finden Sie unter Zugreifen auf SQL Server von einer Webanwendung aus und ASP.NET-Sicherheitsarchitektur.

  • Codezugriffssicherheit   Wenn Ihre Seite den Zugriff auf Ressourcen beinhaltet, die durch verschiedene Zonen geschützt sind, kann die Seite unter ASP.NET Development Server und IIS möglicherweise unterschiedlich ausgeführt werden.

Auch wenn Sie mit dem ASP.NET Development Server die Funktionalität von Webseiten testen können, sollten Sie die Seiten erneut testen, nachdem sie auf einem Produktionswebserver veröffentlicht wurden, auf dem IIS ausgeführt wird.

In einer Dateisystem-Website enthaltene statische Dateien, zum Beispiel Bilder und Stylesheets, unterliegen der ASP.NET-Autorisierung. So werden beispielsweise statische Dateien in einer Dateisystem-Website nicht an anonyme Benutzer übermittelt, wenn der anonyme Zugriff auf diese Dateien deaktiviert wurde. Wenn Sie ein Websiteprojekt jedoch an einem HTTP-Speicherort erstellen, werden beim Übermitteln der statischen Dateien durch IIS die Autorisierungsregeln außer Acht gelassen.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft