Verbesserungen in Visual Studio 2005

von Microsoft

Visual Studio 2005 bietet Webanwendungsentwicklern eine lange Liste von Verbesserungen und Verbesserungen an Webprojekten.

Visual Studio 2005 bietet Webanwendungsentwicklern eine lange Liste von Verbesserungen und Verbesserungen an Webprojekten. So leistungsfähig Visual Studio .NET 2002 und 2003 auch sind, es gab viele Beschwerden in der Art und Weise, wie Webprojekte behandelt wurden. Visual Studio 2005 fügt eine erhebliche Anzahl neuer Features hinzu, um diese Beschwerden zu beheben. Für diejenigen, die die Art und Weise bevorzugen, wie Visual Studio .NET 2003 die Kompilierung von Webanwendungen verarbeitet, finden Sie unter Webanwendungsprojekte.

In diesem Modul behandeln Sie die Verbesserungen bei der Erstellung, Verwaltung und Entwicklung von Webprojekten. In einem späteren Modul behandeln Sie die Verbesserungen beim Erstellen von Webprojekten und deren Bereitstellung.

FrontPage-Servererweiterungen

Visual Studio .NET 2002 und 2003 erforderte FrontPage-Servererweiterungen im Feld, um Webprojekte zu erstellen oder zu erstellen. Entwickler hatten die Wahl zwischen zwei verschiedenen Zugriffsmodi (FrontPage-Servererweiterungen oder Dateizugriffsmodus), beide verwendeten FrontPage-Servererweiterungen, um Aufgaben wie das Festlegen des Anwendungsstamms in IIS usw. auszuführen.

Visual Studio 2005 entfernt die Abhängigkeit von FrontPage-Servererweiterungen für lokale Projekte. Visual Studio 2005 greift jetzt direkt auf die IIS-Metabasis zu, anstatt die FrontPage-Servererweiterungen zu verwenden. Visual Studio 2005 bietet auch Unterstützung für FTP, die den Remoteprojektzugriff ohne FrontPage-Servererweiterungen ermöglicht.

Für Entwickler, die FrontPage-Servererweiterungen in ihren Projekten verwenden möchten, ist die Option weiterhin verfügbar. Basierend auf dem starken Feedback der ASP.NET Entwicklercommunity ist dies jedoch keine Voraussetzung.

Hinweis

FrontPage-Servererweiterungen sind weiterhin für die Remoteprojekterstellung, das Öffnen usw. erforderlich.

Übersicht über ASP.NET Development Server

Visual Studio 2005 wird mit einem neuen Webserver namens ASP.NET Development Server ausgeliefert. (Dieser Webserver war zuvor als Cassini bekannt.)

Es gibt mehrere Vorteile des ASP.NET Development Server.

• Es ist jetzt für Nicht-Administratoren möglich, auf einem Webserver zu entwickeln und zu debuggen.
• Der ASP.NET Development Server ordnet virtuelle Verzeichnisse dynamisch jedem Speicherort im Dateisystem zu, sodass flexible Projektstandorte möglich sind.
• Benutzer unter Windows XP Professional, die bereits IIS verwenden, können jetzt neue Webanwendungen erstellen, die sich nicht auf die Datei- oder Ordnerstruktur ihrer Standardwebsite in IIS auswirken.

Es ist keine spezielle Konfiguration erforderlich, um den ASP.NET Development Server nutzen zu können. Wenn ein Webprojekt, das im Dateisystem gehostet wird, debuggt oder durchsucht wird, startet Visual Studio 2005 automatisch eine instance des ASP.NET Development Server an einem zufälligen Port, um die Anforderung zu verarbeiten.

Weitere Informationen finden Sie weiter unten in diesem Modul auf dem ASP.NET Development Server.

Verbesserte Dateiverwaltung

In Visual Studio 2002 und 2003 wurden in einer Projektdatei (.vbproj für VB.NET und .csproj für C#) Informationen zu allen Dateien in der Webanwendung gespeichert. Die Projektmappen-Explorer Anzeige basiert auf den Dateiinformationen in der Projektdatei. Aus diesem Fall zeigte die Projektmappen-Explorer häufig ungenaue Informationen an, wenn externe Editoren verwendet wurden. In Visual Studio 2002 und 2003 wurden Dateiänderungen häufig überschrieben oder die neueste Version von Dateien nicht angezeigt.

Visual Studio 2005 beseitigt die Projektdatei. Stattdessen werden die Datei- und Ordnerinformationen direkt vom Datenträger gelesen, was zu einer genauen Anzeige der Dateien in Ihrem Projekt führt. Da der Ordner Verweise in Visual Studio 2002 und 2003 keinen tatsächlichen Ordner in Ihrer Webanwendung darstellt, entfernt Visual Studio 2005 auch den Ordner Verweise aus Projektmappen-Explorer. Um auf die Verweise für Ihr Projekt in Visual Studio 2005 zuzugreifen, sollten Sie die Eigenschaftenseiten für das Projekt verwenden.

Erstellen von Webprojekten

Webentwickler haben viele neue Optionen für die Projekterstellung in Visual Studio 2005 zur Verfügung. Websites können jetzt an einer beliebigen Stelle im Dateisystem erstellt und dann mithilfe des neuen ASP.NET Development Server debuggen oder durchsucht werden. Entwickler können auch neue Websites mithilfe von FTP erstellen.

Klicken Sie hier, um eine exemplarische Videoanleitung zum Erstellen von Webprojekten in Visual Studio 2005 anzuzeigen.

Video Full-Screen öffnen

Dateisystemprojekte

Wie Sie in der exemplarischen Vorgehensweise im Video gesehen haben, können Sie über eine Dateifreigabe Websites im Dateisystem entweder auf dem lokalen Computer oder an einem Remotespeicherort erstellen. Websites, die im Dateisystem erstellt werden, werden mithilfe des ASP.NET Development Server durchsucht und debuggen.

Hinweis

Der ASP.NET Development Server kann für Kunden verwirrung sorgen. Wenn ein Webprojekt im Dateisystem in der IISs-Verzeichnisstruktur (d. h. c:/inetpub/wwwroot) erstellt wird, wird die Website weiterhin über den ASP.NET Development Server durchsucht, wenn sie in Visual Studio 2005 gestartet wird. Daher ist jede IIS-Konfiguration (d. h. Authentifizierungsmethoden) nicht anwendbar.

Das Standardwebprojekt entfernt auch einen Großteil des Mehraufwands, indem nur eine Default.aspx-Seite, die Datei default.cs und ein Ordner App/_Data enthalten sind. Die web.config und speziellen Ordner (d. h. app/_code) werden nach Bedarf hinzugefügt. Ihr Webprojekt enthält nur die Dateien und Ordner, die Sie benötigen.

HTTP-Projekte

HTTP-Projekte können entweder Projekte sein, die auf einer lokalen IIS-Website oder auf einer Remotewebsite erstellt werden. Der Standardprojektspeicherort ist http://localhost. Wenn Sie auf die Schaltfläche Durchsuchen klicken, gibt es zwei HTTP-Optionen: Lokaler IIS und Remotestandort. Der Standard Unterschied in diesen beiden Optionen ist die Methode, in der die Websiteinformationen im Dialogfeld Speicherort auswählen angezeigt werden und wie die Dateien auf den Webserver kopiert werden.

Die Option Lokaler IIS liest die Websiteinformationen aus der Metabasis auf dem lokalen Computer, und Dateien werden mithilfe des Dateisystems kopiert. Die Option Remotewebsite verwendet die FrontPage-Servererweiterungen, und die Websiteinformationen und Dateien werden mithilfe von RPC-Aufrufen von HTTP- und FrontPage-Servererweiterungen kopiert.

Hinweis

Die Vs###/_tmp.htm-Datei und get/_aspx/_ver.aspx werden nicht mehr zum Ermitteln von Versionsinformationen verwendet.

Die HTTP-Standardoption ist Lokaler IIS. Mit dieser Option wird die IIS-Metabasis gelesen, um zu ermitteln, welche Websites verfügbar sind und wo Inhalte erstellt werden sollen. Sie können einen anderen Ordner oder ein anderes virtuelles Verzeichnis auswählen, indem Sie es in der Strukturansicht auswählen. Sie können auch ein neues virtuelles Verzeichnis erstellen, Ordner als Anwendungen markieren und vorhandene virtuelle Verzeichnisse aus diesem Dialogfeld löschen.

Abbildung 1: Dialogfeld "Standort auswählen"

Wenn Sie im Gegensatz zu früheren Versionen von Visual Studio das Kontrollkästchen Secure Sockets Layer verwenden aktivieren und das SSL-Zertifikat nicht mit der URL übereinstimmt, die Sie durchsuchen, wird ein Dialogfeld "Sicherheitswarnung" angezeigt, in dem Sie gefragt werden, ob Sie fortfahren möchten. Wenn das Zertifikat bei Visual Studio .NET 2003 nicht übereinstimmend war, schlägt das Erstellen des Projekts fehl.

Abbildung 2: Sicherheitswarnung bezüglich des SSL-Zertifikats

Hinweis zu Hostheadern

Wenn Sie eine Webanwendung auf einer Website erstellen, die an eine bestimmte IP-Adresse gebunden ist, müssen Sie sicherstellen, dass ein Hostheader konfiguriert ist. Andernfalls erstellt Visual Studio die Website unter http://localhost, aber die IP-Adresse wird nicht ordnungsgemäß aufgelöst, wenn die Website in der IDE durchsucht oder debuggen wird.

Wenn Sie die Option Remotewebsite auswählen, ändert sich das Dialogfeld, sodass Sie die Ziel-URL für die neue Website eingeben können. Diese URL muss sich auf einem Server befinden, auf dem die FrontPage-Servererweiterungen aktiviert sind. Wenn Sie mit Ihrem lokalen Webserver mithilfe der FrontPage-Servererweiterungen arbeiten möchten, können Sie die Option Remotewebsite verwenden und eine lokale URL angeben.

Abbildung 3: Erstellen einer Website auf einem Remoteserver

Beim Erstellen einer Anwendung an einem Remotestandort per SSL unterscheidet sich das Bestätigungsdialogfeld geringfügig von dem Dialogfeld, das bei Verwendung der Option Lokale IIS angezeigt wird, wenn das SSL-Zertifikat nicht übereinstimmt.

Abbildung 4: Warnung zur Remotesitesicherheit

FTP

Visual Studio 2005 führt die Option zum Erstellen von Websites per FTP ein. Wenn Sie diese Option verwenden, erstellt die IDE die Dateien lokal im temporären Benutzerordner und verwendet dann FTP, um die Dateien an den FTP-Speicherort zu verschieben.

Hinweis

Der Speicherort des temporären Ordners lautet c:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>

Wenn Sie die FTP-Option verwenden, wird ein Dialogfeld Speicherort auswählen angezeigt. Sie geben die erforderlichen FTP-Verbindungsinformationen in dieses Dialogfeld ein, wie unten gezeigt.

Abbildung 5: Dialogfeld Speicherort auswählen für FTP

Lab: Einrichten einer FTP-Website und Erstellen eines Projekts

Mit den folgenden Schritten wird die FTP-Website so konfiguriert, dass ein Benutzer über einen Speicherort verfügt, an den nur er per FTP hochladen kann.

Installieren des FTP-Diensts

1. Öffnen Sie Programme hinzufügen, und wählen Sie Windows-Komponenten hinzufügen/entfernen aus.
2. Wählen Sie Internetinformationsdienste (Anwendungsserver unter Windows 2003) aus, und klicken Sie auf Details.
3. Aktivieren Sie den FTP-Dienst (File Transfer Protocol), und klicken Sie auf OK.
4. Klicken Sie auf Weiter , um den FTP-Dienst zu installieren.

Erstellen eines neuen Ordners für Inhalte

1. Erstellen Sie in Windows Explorer einen neuen Ordner namens User1 in c:/inetpub/wwwroot.

Konfigurieren Sie Ordner und Berechtigungen für Ordner.

1. Öffnen Sie das Snap-In Internetinformationsdienste über Die Verwaltung. Sie verfügen nun über einen Ordner FTP-Standorte unter dem Knoten Computername.
2. Erweitern Sie FTP-Sites.
3. Klicken Sie mit der rechten Maustaste auf den Standard-FTP-Standort, wählen Sie Neu und dann Virtuelles Verzeichnis aus, und klicken Sie dann auf Weiter.
4. Geben Sie User1 für den Namen des virtuellen Verzeichnisses ein, und klicken Sie auf Weiter.
5. Geben Sie als Pfad c:/inetpub/wwwroot/User1 ein, und klicken Sie auf Weiter.
6. Klicken Sie auf Weiter und dann auf Fertig stellen , um den Assistenten abzuschließen.
7. Klicken Sie mit der rechten Maustaste unter Standard-FTP-Standort auf das virtuelle Verzeichnis User1 , und wählen Sie Eigenschaften aus.
8. Aktivieren Sie das Kontrollkästchen Schreiben , und klicken Sie auf OK , um das Dialogfeld zu schließen.
9. Klicken Sie mit der rechten Maustaste auf Standard-FTP-Site , und wählen Sie Eigenschaften aus.
10. Deaktivieren Sie auf der Registerkarte Sicherheitskontendie Option Anonyme Verbindungen zulassen.
11. Klicken Sie im Dialogfeld auf Ja und fragen Sie, ob Sie fortfahren möchten.
12. Klicken Sie auf OK, um das Dialogfeld zu schließen.
13. Erweitern Sie die Standardwebsite unter dem Knoten Websites .
14. Klicken Sie mit der rechten Maustaste auf das Verzeichnis User1 , und wählen Sie Eigenschaften aus.
15. Klicken Sie im Abschnitt Anwendungseinstellungen auf Erstellen , um den Ordner als Anwendung zu markieren.
16. Klicken Sie auf OK, um das Dialogfeld zu schließen.
17. Schließen Sie das Snap-In Internetinformationsdienste.

Erstellen eines Webprojekts

1. Öffnen Sie Visual Studio 2005.
2. Wählen Sie im Menü Dateidie Option Neue Website aus.
3. Wählen Sie in der Dropdownliste Speicherortdie Option FTP aus.
4. Klicken Sie auf Durchsuchen.
5. Geben Sie localhost in das Textfeld Server ein.
6. Geben Sie Benutzer1 in das Textfeld Verzeichnis ein.
7. Klicken Sie auf Öffnen. Der FTP-Speicherort wird in das Dialogfeld Neue Website eingegeben.
8. Klicken Sie auf OK.
9. Deaktivieren Sie anonymes Anmelden im Dialogfeld FTP-Anmeldung, geben Sie Ihre Anmeldeinformationen ein, und klicken Sie auf OK.
10. Was ist die URL für das Projekt? (Die URL für das Projekt wird in Projektmappen-Explorer angezeigt.)
11. Wählen Sie im Menü Erstellen die Option Website erstellen oder Projektmappe erstellen aus.
12. Klicken Sie mit der rechten Maustaste in Projektmappen-Explorer auf Default.aspx, und wählen Sie Im Browser anzeigen aus.
13. Geben Sie im Dialogfeld Website-URL erforderlich für die URL ein http://localhost/user1 , und klicken Sie auf OK.

Hinweis

Wenn Sie eine Fehlermeldung erhalten, die darauf hinweist, dass der Typ /_Default nicht geladen werden kann, stellen Sie sicher, dass Sie ASP.NET 2.0 auf Ihrer Website und nicht eine frühere Version ausführen. Sie können dies über die Registerkarte ASP.NET unter Internetinformationsdienste tun.

Öffnen von Webprojekten

Das Öffnen von Webprojekten ähnelt dem Erstellen von Projekten. In den folgenden Abschnitten werden Bereiche aufgeführt, auf die Sie achten müssen, während Sie innerhalb der IDE arbeiten. Außerdem wird die Arbeit mit Webprojekten mit HTTP und FTP behandelt.

Wählen Sie zum Öffnen eines Webprojekts im Menü Datei die Option Website öffnen aus. Sie werden mit demselben Dialogfeld Speicherort auswählen aufgefordert, das zuvor behandelt wurde, und Ihnen stehen die gleichen vier Optionen zur Verfügung: Dateisystem, Lokaler IIS, FTP und Remotestandort.

Dateisystem

Wie bereits in diesem Modul beschrieben, verwendet Visual Studio keine Projektdatei mehr. Wenn Sie also eine Website über das Dateisystem öffnen möchten, haben Sie tatsächlich die Möglichkeit, einen beliebigen Ordner auszuwählen, auch wenn der ausgewählte Ordner zunächst nicht als Webprojekt in Visual Studio erstellt wurde. Beispielsweise können Sie den Ordner "Eigene Dokumente" als Website öffnen. Visual Studio öffnet ihn gerne und zeigt Ihre Dateien wie unten dargestellt an.

Abbildung 6: Als Website geöffnete Dokumente

Da Visual Studio nur bei Bedarf zusätzliche Dateien und Ordner erstellt, werden dem geöffneten Speicherort keine zusätzlichen Dateien oder Ordner hinzugefügt. Ein Nebeneffekt dieser Architektur ist, dass sie verhindert, dass Websites im Dateisystem geschachtelt werden. Betrachten Sie beispielsweise die folgende Verzeichnisstruktur.

Webprojekt unter C:/MyWebSite

Ein weiteres Webprojekt unter C:/MyWebSite/Nested

Wenn Sie die Website unter c:/MyWebSite öffnen, wird der geschachtelte Ordner als Unterordner dieser Anwendung angezeigt.

HTTP

Beim Öffnen von Websites über HTTP werden Einstellungen entweder aus der IIS-Metabasis (Local IIS) oder mithilfe von FrontPage-Servererweiterungen (Remotewebsite) gelesen. Wenn geschachtelte Webanwendungen vorhanden sind, werden diese ebenfalls mit einem Symbol angezeigt, das sie als Anwendung identifiziert. Wenn Sie mit der Arbeit mit Webanwendungen in FrontPage vertraut sind, ist das Verhalten in Visual Studio 2005 ähnlich.

Obwohl Visual Studio ein Symbol für Anwendungen anzeigt, die unter der Anwendung geschachtelt sind, die derzeit in der IDE geöffnet ist, können Sie sie nicht erweitern, um ihren Inhalt anzuzeigen. Sie können jedoch auf sie doppelklicken, um sie zu öffnen. Wenn Sie dies tun, wird ein Dialogfeld angezeigt, in dem Sie aufgefordert werden, entweder die Webanwendung zu öffnen (und die aktuell geöffnete Lösung zu ersetzen) oder die Webanwendung ihrer aktuellen Lösung hinzuzufügen.

Abbildung 7: Doppelklicken auf ein geschachteltes Anwendungssymbol zeigt Ihnen dieses Dialogfeld an.

FTP-Site

Wenn Sie eine Website über FTP öffnen, werden die Dateien alle lokal in Ihren temporären Ordner kopiert. Der vollständige Pfad für den lokalen Speicherort wird im Bereich Eigenschaften des Projekts angezeigt und im folgenden Format erstellt.

C:/Dokumente und Einstellungen/<Benutzer>/Lokale Einstellungen/Temp/VWDWebCache/<Server>/_<Application Name>

Wenn Sie FTP verwenden, muss Visual Studio die Basis-URL für Ihr Projekt angeben, damit Sie es wie unten dargestellt durchsuchen können. Wenn Sie keine Basis-URL angeben, werden Sie von Visual Studio gefragt, wenn Sie zum ersten Mal versuchen, eine Seite auf der Website zu durchsuchen.

Abbildung 8: Angeben einer Basis-URL für FTP-Websites

Verbesserungen bei der Kompilierung

Die Arbeit mit Webanwendungen in Visual Studio 2005 ist deutlich schneller als frühere Versionen. Dies ist nicht zuletzt auf die Änderungen in der Kompilierungsarchitektur zurückzuführen.

In Visual Studio 2002 und 2003 wurden Webanwendungen zu einer primären Assembly kompiliert, die sich im Ordner /bin befindet. In Visual Studio 2005 wurde ein Ordner App/_Code hinzugefügt. Klassen und anderer Nicht-UI-Code werden dem Ordner App/_Code hinzugefügt. Wenn Visual Studio das Projekt erstellt, werden alle Dateien im Ordner App/_Code in eine einzelne App/_Code.dll-Datei kompiliert. Das Ergebnis dieser Änderung ist, dass nachfolgende Builds viel schneller als in früheren Versionen sind.

Hinweis

Das Befehlszeilenprogramm MSBuild kann auch verwendet werden, um ASP.NET Webanwendungen zu erstellen. Dieses Tool wird in Modul 9 behandelt.

Eine weitere Kompilierungsverbesserung ist die neue Option Seite erstellen im Menü Erstellen. Mit diesem Feature kann ein Entwickler nur die aktuelle Seite (zusammen mit natürlich und Abhängigkeiten) neu erstellen, sodass Änderungen schneller kompiliert werden können. Da C# keine Hintergrundkompilierung zum Aktualisieren von IntelliSense usw. bietet, profitieren sie erheblich von diesem Feature, da intelliSense schnell aktualisiert werden kann, indem einfach eine einzelne Seite neu erstellt wird.

Mit den Buildeigenschaften für ein Projekt können Sie den Typ des Builds konfigurieren, der vor der Ausführung der Startseite erfolgt. Entwickler können nur die aktuelle Seite erstellen, damit Visual Studio das Debuggen von Anwendungen nach Codeänderungen schneller starten kann.

Abbildung 9: Startaktion der Buildseite

Eine weitere großartige Verbesserung von Visual Studio und der ASP.NET-Architektur ist der Bereich bearbeiten und fortfahren. In Visual Studio 2005 können Entwickler mit dem Debuggen eines Projekts beginnen und Codeänderungen am Projekt vornehmen, ohne den Debugger zu trennen. In der Tat können Sie buchstäblich mit dem Debuggen eines Projekts beginnen, eine neue Klasse hinzufügen, dieser Klasse Code hinzufügen, Ihrer Seite Code hinzufügen, der eine neue instance dieser Klasse erstellt, und eine Methode der -Klasse ausführen, ohne den Debugger zu trennen. Das Ausführen des neuen Codes ist buchstäblich so einfach wie das Aktualisieren des Browsers!

Klicken Sie hier, um eine exemplarische Vorgehensweise zum Bearbeiten und Fortfahren in Visual Studio 2005 anzuzeigen.

Full-Screen Video öffnen

Die robuste Bearbeitungs- und Weiterführungsfunktionalität in ASP.NET 2.0 und Visual Studio 2005 ist auf eine architektonische Änderung für ASP.NET-Anwendungen zurückzuführen. In ASP.NET 1.x wurden in Visual Studio 2002/2003 erstellte Anwendungen in eine primäre Assembly kompiliert, die im Ordner /bin gespeichert wurde. Alle Klassen, Seiten usw. für die Anwendung wurde in diese eine DLL kompiliert. Zur Laufzeit kompilierte ASP.NET dann alle Steuerelemente, Markups und ASP.NET Code innerhalb von Seiten und kopierte diese DLLs in den ASP.NET temporären Ordner.

In Visual Studio 2005 mit ASP.NET 2.0 wurden die beiden oben beschriebenen Kompilierungsmodelle (eines für Visual Studio und eines für ASP.NET zur Laufzeit) in einem gemeinsamen Kompilierungsmodell zusammengeführt. Das bedeutet, dass alle Kompilierungsprobleme jetzt während der Entwicklungsphase und nicht zur Laufzeit abgefangen werden. Es ermöglicht auch designer- und IntelliSense-Unterstützung für Features wie Benutzersteuerelemente und master Seiten.

Klicken Sie hier, um eine exemplarische Videoanleitung zur Unterstützung von Designern für Benutzersteuerelemente anzuzeigen.

Full-Screen Video öffnen

Hinweis

Wenn ein Benutzersteuerelement von einer Seite entfernt wird, verbleibt die @Register -Direktive im Markup und sollte manuell entfernt werden, um Parserfehler zu vermeiden, wenn das Benutzersteuerelement von der Website gelöscht wird.

Eine weitere Verbesserung des Visual Studio-Kompilierungsmodells ist das Feature Website veröffentlichen. Da die Veröffentlichungsfunktion die Website vorkompiliert, können Entwickler von der zusätzlichen Leistung profitieren, wenn sie keine Kompilierung bei Bedarf durchführen müssen. Außerdem wird der gesamte Quellcode im Ordner App/_Code in einer DLL vorkompiliert, sodass kein Quellcode bereitgestellt werden muss.

Abbildung 10: Dialogfeld "Website veröffentlichen"

Hinweis

Das Hilfsprogramm aspnet/_compile.exe kann auch verwendet werden, um eine ASP.NET Webanwendung vorzukompilieren. Dieses Tool wird in Modul 9 behandelt.

Wenn Sie eine Website veröffentlichen, werden die vorkompilierten Dateien wie unten gezeigt im Ordner Temporäre ASP.NET Dateien gespeichert. Dateien mit der Dateierweiterung .compiled sind XML-Dateien, die Abhängigkeiten für bestimmte DLLs definieren. Alle Webformular- oder Benutzersteuerelemente werden in zufällige DLLs kompiliert, die mit App/Web/ beginnen.

Wenn Sie das Kontrollkästchen Diese vorkompilierte Website aktualisierbar zulassen aktiviert lassen, wird das Markup innerhalb Ihrer Webformulare und Benutzersteuerelemente nicht in eine DLL vorkompiliert, sodass Sie nach der Bereitstellung Änderungen vornehmen können. Wenn Sie das Markup sperren möchten, damit Änderungen am bereitgestellten Inhalt nicht zulässig sind, deaktivieren Sie dieses Kontrollkästchen.

Mit dem Kontrollkästchen Feste Benennung und Assemblys für einzelne Seiten verwenden können Sie die Batchkompilierung deaktivieren, sodass jede Seite in eine Assembly mit festem Namen kompiliert wird. Wenn Sie dieses Kontrollkästchen deaktiviert lassen, können Sie die Batchkompilierung nutzen.

Mit dem Kontrollkästchen Starke Benennung für vorkompilierte Assemblys aktivieren können Sie Ihre vorkompilierten Assemblys stark benennen.

Hinweis

In ASP.NET Version 1.x mussten Assemblys mit starkem Namen im globalen Assemblycache (GAC) installiert werden. In ASP.NET 2.0 müssen Sie keine Assemblys mit starkem Namen im GAC installieren.

Abbildung 11: Vorkompilierte Dateien für ASP.NET Anwendungen

Hinweis

In der obigen Anwendung gab es keine web.config Datei. Wenn es vorhanden wäre, wäre es nach dem Veröffentlichungsvorgang der WebsitePrecompiledApp.configaufgerufen worden.

Verbesserungen bei der Bereitstellung

Wie bei Visual Studio 2002 und 2003 bietet Visual Studio 2005 das Feature Projekt kopieren. Das Feature wurde jedoch in Visual Studio 2005 überarbeitet und heißt jetzt Website kopieren.

Das Dialogfeld Website kopieren ist in einen linken Und einen rechten Frame unterteilt. Der linke Frame wird als Quellwebsite und der rechte Frame als Remotewebsite bezeichnet. Eine Sache, die einige Entwickler verwirren kann, ist, dass die im rechten Frame angezeigte Website nicht unbedingt eine Remotewebsite ist. Es kann sich um eine Website im lokalen Dateisystem oder auf der lokalen instance von IIS sein. Darüber hinaus ist die im linken Frame angezeigte Website nicht notwendigerweise die Quellwebsite, da sie über das Dialogfeld von der Remotewebsite in der Quellwebsite veröffentlichen können.

Wenn Sie ein Projekt auf eine Remotewebsite kopieren, müssen auf dieser Website die FrontPage-Servererweiterungen installiert sein. Wenn dies nicht der Fall ist, müssen Sie eine Verbindung über FTP herstellen. Wenn Sie dagegen ein Projekt in die lokale IIS-instance kopieren, sind FrontPage-Servererweiterungen nicht erforderlich.

Hinweis

Wenn Sie versuchen, eine neue Website auf der lokalen IIS-instance zu erstellen und die FrontPage 2002-Servererweiterungen installiert sind, erhalten Sie eine Fehlermeldung, die Sie darüber informiert, dass das Erstellen von Websites auf einem SharePoint-Server nicht unterstützt wird. In diesem Fall haben Sie die Möglichkeit, die FrontPage 2000-Servererweiterungen zu installieren oder die FrontPage-Servererweiterungen zu entfernen.

Klicken Sie hier, um eine exemplarische Videoanleitung zum Feature "Website kopieren" anzuzeigen.

Full-Screen Video öffnen

Verbesserungen beim Debuggen

Es gibt vier wichtige Verbesserungen beim Debuggen in Visual Studio 2005.

• Das lokale Debuggen als Nicht-Administrator ist sofort möglich.
• Das Debug-Attribut für das Compilation-Element ist jetzt standardmäßig false.
• Die Einrichtung und Konfiguration des Remotedebuggens ist einfacher als zuvor.
• Sie können jetzt eine Website debuggen, die über einen FTP-Speicherort geöffnet wurde.

Debuggen als Nicht-Administrator

Durch die Hinzufügung des ASP.NET Development Server können Nichtadministratoren ASP.NET Anwendungen sofort debuggen. Wenn eine ASP.NET Anwendung, die im lokalen Dateisystem ausgeführt wird, debuggt wird, startet Visual Studio den ASP.NET Development Server im Kontext des angemeldeten Benutzers. Dieser Benutzer kann diese Anwendung dann ohne zusätzliche Konfiguration debuggen.

Debug ist standardmäßig false.

In ASP.NET 1.x wurde das Debug-Attribut im Kompilierungselement der web.config-Datei standardmäßig auf TRUE festgelegt. Es wurde immer empfohlen, dass Entwickler dieses Attribut auf false festlegen, bevor sie eine Anwendung in der Produktion bereitstellen. Da die meisten Entwickler jedoch die Folgen nicht vollständig verstehen, wenn das Debug-Attribut auf true festgelegt wird, haben sie es einfach unverändert gelassen.

Das schwerwiegendste Problem bei der Festlegung des Debug-Attributs auf true ist, dass ASP deaktiviert wird. NETs-Batchkompilierungsmodell. Daher wird jede Seite in eine separate DLL kompiliert. Wenn eine Webanwendung aus Tausenden von Seiten besteht (nicht unerhört), bedeutet dies, dass mehrere Tausend kleine DLLs von dieser Anwendung erstellt werden. Obwohl diese DLLs klein sind, werden sie nicht an einen bestimmten Speicherort im Arbeitsspeicher geladen. Daher verursachen sie eine Fragmentierung im Systemspeicher und können zu OutOfMemoryException-Vorkommen beitragen.

In ASP.NET 2.0 ist das Debug-Attribut standardmäßig auf false festgelegt. Wie Sie bereits gesehen haben, wird ein Entwickler beim Debuggen einer ASP.NET-Anwendung in Visual Studio 2005 aufgefordert, eine web.config-Datei mit aktiviertem Debuggen hinzuzufügen. Dies hat die gleichen Nachteile, die in ASP.NET 1.x vorhanden waren, aber jetzt wird der Entwickler deutlich gewarnt, dass das Attribut auf false zurückgesetzt werden sollte, bevor die Anwendung in die Produktion verschoben wird.

Setup und Konfiguration des Remotedebuggens

In Visual Studio 2002/2003 basiert das Remotedebuggen auf dem Machine Debug Manager (mdm.exe) und dem vs7jit.exe Prozess. Aus diesem Grund war die Problembehandlung beim Remotedebuggen für Kunden oft eine Blackbox und oft nicht viel besser für PSS.

Visual Studio 2005 entfernt die Abhängigkeit von den mdm.exe- und vs7jit.exe prozessen. Stattdessen wird jetzt der Remotedebugmonitordienst (msvsmon.exe) verwendet.

Die Anforderung für das Remotedebuggen in Visual Studio 2005 ist recht einfach. Sie müssen vor dem Debuggen msvsmon.exe auf dem Remoteserver ausführen. Sie können den Remotedebugmonitor von der Visual Studio-CD installieren, oder Sie können einfach msvsmon.exe aus einer Freigabe ausführen, ohne etwas auf dem Webserver zu installieren.

Wenn Sie msvsmon.exe ausführen, wird sie sich wahrscheinlich darüber beschweren, dass Ports für das Remotedebuggen blockiert werden. Glücklicherweise können Sie die Blockierung der Ports ganz einfach direkt im Warnungsdialogfeld aufheben, wie unten gezeigt.

Abbildung 12: Benachrichtigung, dass die Windows-Firewall das Remotedebuggen blockiert

Nachdem Sie die Blockierung der für das Debuggen erforderlichen Ports aufgehoben haben, wird der Remotedebugmonitor wie unten gezeigt angezeigt. Über diese Schnittstelle können Sie Verbindungen überwachen und Debugberechtigungen einfach ändern.

Abbildung 13: Remotedebugmonitor

Es ist auch möglich, eine per FTP geöffnete Webanwendung remote zu debuggen. Die Schritte sind identisch mit denen, die zuvor behandelt wurden. Sie müssen jedoch eine Basis-URL für das Durchsuchen des FTP-Projekts angeben, wie weiter oben in diesem Modul beschrieben.

Lab 2

Remotedebuggen mit Visual Studio 2005

Dieses Lab führt Sie durch das Remotedebuggen mit Visual Studio 2005.

Klicken Sie hier, um eine exemplarische Videoanleitung für dieses Lab anzuzeigen.

Full-Screen Video öffnen

Für dieses Lab müssen Sie über zwei Computer verfügen, auf denen einer Visual Studio 2005 und auf dem anderen IIS 5 oder höher ausgeführt wird.

1. Öffnen Sie Visual Studio 2005, und erstellen Sie eine neue Website auf dem Remoteserver.

Hinweis

Sie können die Website auf einem REMOTE-IIS-instance oder per FTP erstellen.

1. Suchen Sie auf dem Remotewebserver msvsmon.exe auf dem Entwicklungscomputer mithilfe eines UNC-Pfads, und führen Sie ihn aus.
   Der Standardspeicherort für msvsmon.exe ist //server/c$/Programme/Microsoft Visual Studio 8/Common7/IDE/Remotedebugger/x86.
2. Wenn Sie aufgefordert werden, die Blockierung von Ports für das Remotedebugging aufzuheben, tun Sie dies.
3. Öffnen Sie auf dem Entwicklungscomputer den CodeBehind für Default.aspx, und legen Sie einen Haltepunkt in der Page/_Load-Methode fest.
4. Starten Sie das Debuggen auf dem Entwicklungscomputer.

Sie sollten den Haltepunkt wie erwartet erreichen.

Starten ASP.NET Development Server

Wie bereits erläutert, wird Visual Studio 2005 mit einem Webserver namens ASP.NET Development Server ausgeliefert. (Der ASP.NET Development Server wird manchmal als Cassini bezeichnet.) Dieser Webserver ist ein praktisches Mittel zum Durchsuchen und Debuggen von Webanwendungen, die im Dateisystem ausgeführt werden.

Der ASP.NET Development Server ist ein eingeschränkter Webserver. Es lässt keine Remoteverbindungen zu, es lässt keine Anforderungen von einem anderen Benutzer als dem Benutzer zu, der den Webserver gestartet hat. Es verfügt auch nicht über die Möglichkeit, ASP-Seiten zu bereitstellen. Es werden nur ASP.NET Ressourcen und HTML-Ressourcen (einschließlich Bildern, CSS-Dateien usw.) bereitgestellt.

Der ASP.NET Development Server kann über die Befehlszeile gestartet werden, indem Sie die datei WebDev.WebServer.exe unter c:/Windows/Microsoft.NET/Framework/v2.0.////*ausführen. Im folgenden Dialogfeld werden die verfügbaren Parameter angezeigt.

Abbildung 14

Hinweis

Der ASP.NET Development Server wird nicht unterstützt, wenn er explizit über die Befehlszeile gestartet wird.