Verbesserungen in Visual Studio 2005

von Microsoft

Visual Studio 2005 liefert Webanwendungsentwicklern eine lange Liste von Verbesserungen und Erweiterungen für Webprojekte.

Visual Studio 2005 bietet Webanwendungsentwicklern eine lange Liste von Verbesserungen und Erweiterungen für Webprojekte. So leistungsfähig wie Visual Studio .NET 2002 und 2003 sind, gibt es viele Beschwerden, wie Webprojekte behandelt wurden. Visual Studio 2005 fügt eine erhebliche Anzahl neuer Features hinzu, um diese Beschwerden zu beheben. Informationen dazu, wie Visual Studio .NET 2003 die Kompilierung von Webanwendungen behandelt, finden Sie unter "Webanwendungsprojekte".

In diesem Modul behandeln wir Verbesserungen bei der Erstellung, Verwaltung und Entwicklung von Webprojekten. In einem späteren Modul behandeln wir Verbesserungen beim Erstellen und Bereitstellen von Webprojekten.

FrontPage-Servererweiterungen

Visual Studio .NET 2002 und 2003 erforderten FrontPage-Servererweiterungen, die auf dem System installiert waren, um Webprojekte erstellen oder entwickeln zu können. Entwickler haben eine Wahl zwischen zwei verschiedenen Zugriffsmodi (FrontPage-Servererweiterungen oder Dateizugriffsmodus), beide haben FrontPage-Servererweiterungen verwendet, um Aufgaben auszuführen, z. B. das Festlegen des Anwendungsstamms in IIS usw.

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 ermöglicht, ohne dass FrontPage-Servererweiterungen erforderlich sind.

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

Übersicht über ASP.NET Development Server

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

Es gibt mehrere Vorteile des ASP.NET Development Server.

• Es ist jetzt möglich, dass Nichtadministratoren einen Webserver entwickeln und debuggen können.
• Der ASP.NET Development Server ordnet virtuelle Verzeichnisse dynamisch jedem Speicherort im Dateisystem zu, sodass flexible Projektspeicherorte möglich sind.
• Benutzer unter Windows XP Professional, die iis bereits 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 zu nutzen. Wenn ein Webprojekt, das im Dateisystem gehostet wird, gedebuggt oder durchsucht wird, startet Visual Studio 2005 automatisch eine Instanz des ASP.NET Development Server auf einem zufälligen Port zum Dienst der Anforderung.

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

Verbesserte Dateiverwaltung

In Visual Studio 2002 und 2003 speicherte eine Projektdatei (VBPROJ für VB.NET und CSPROJ für C#) Informationen zu allen Dateien in der Webanwendung. Die Anzeige des Solution Explorers basiert auf den Dateiinformationen in der Projektdatei. Aus diesem Gründen würde der Projektmappen-Explorer häufig ungenaue Informationen in Fällen anzeigen, in denen externe Editoren verwendet wurden. Visual Studio 2002 und 2003 überschreiben häufig Dateiänderungen oder zeigen nicht die neueste Version von Dateien an.

Visual Studio 2005 entfernt 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 dem 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. Websites können jetzt an einer beliebigen Stelle im Dateisystem erstellt und dann mit dem neuen ASP.NET Development Server gedebuggt oder durchsucht werden. Entwickler können auch neue Websites mithilfe von FTP erstellen.

Klicken Sie hier, um ein Video mit einer Anleitung zum Erstellen von Webprojekten in Visual Studio 2005 anzusehen.

Full-Screen Video öffnen

Dateisystemprojekte

Wie im Video-Walkthrough gesehen, können Sie auswählen, Websites auf dem Dateisystem entweder auf dem lokalen Computer oder auf einem Remotespeicherort über eine Dateifreigabe zu erstellen. Websites, die im Dateisystem erstellt werden, werden mithilfe des ASP.NET Development Server durchsucht und gedebuggt.

Das Standardwebprojekt entfernt außerdem viel Mehraufwand, indem nur eine Default.aspx Seite, default.cs Datei und ein App/_Data Ordner enthalten ist. Die web.config und speziellen Ordner (i.e. app/_code) werden nach Bedarf hinzugefügt. Ihr Webprojekt enthält nur die benötigten Dateien und Ordner.

HTTP-Projekte

HTTP-Projekte können 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: lokales IIS und Remotesite. Der Hauptunterschied bei diesen beiden Optionen ist die Methode, in der die Websiteinformationen im Dialogfeld "Speicherort auswählen" und in der Art und Weise, wie die Dateien auf den Webserver kopiert werden, angezeigt werden.

Die Option "Lokales 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 HTTP- und FrontPage Server Extensions RPC-Aufrufe kopiert.

Die Standardmäßige HTTP-Option ist lokales IIS. Mit dieser Option wird die IIS-Metabasis gelesen, um zu bestimmen, welche Websites verfügbar sind, und den Speicherort, an dem Inhalte erstellt werden sollen. Sie können einen anderen Ordner oder ein anderes virtuelles Verzeichnis auswählen, indem Sie ihn in der Strukturansicht auswählen. Sie können auch ein neues virtuelles Verzeichnis erstellen, Ordner als Anwendungen markieren sowie vorhandene virtuelle Verzeichnisse aus diesem Dialogfeld löschen.

Abbildung 1: Das Dialogfeld "Speicherort 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 ihnen ein Dialogfeld mit der Sicherheitswarnung angezeigt, in dem Sie gefragt werden, ob Sie fortfahren möchten. Bei der Verwendung von Visual Studio .NET 2003 schlägt das Erstellen des Projekts fehl, wenn das Zertifikat nicht übereinstimmt.

Abbildung 2: Sicherheitswarnung bezüglich SSL-Zertifikat

Hinweis zu Hostheadern

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

Wenn Sie die Option "Remotewebsite" auswählen, ändert sich das Dialogfeld, damit 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 auf einem Remotestandort über SSL, wenn das SSL-Zertifikat nicht übereinstimmt, unterscheidet sich das Bestätigungsdialogfeld geringfügig von dem Dialogfeld, das bei der Verwendung der Option "Lokales IIS" angezeigt wird.

Abbildung 4: Sicherheitswarnung für Remotestandorte

FTP

Visual Studio 2005 führt die Option zum Erstellen von Websites über 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.

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

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

Lab: Einrichten einer FTP-Website und Erstellen eines Projekts

Mit den folgenden Schritten wird der FTP-Standort so konfiguriert, dass ein Benutzer über einen Ort verfügt, an den nur er über FTP hochladen kann.

Installieren des FTP-Diensts

1. Öffnen Sie "Programme hinzufügen", 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. Überprüfen 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 " innerhalb von "c:/inetpub/wwwroot".

Konfigurieren Sie Ordner und Berechtigungen für Ordner.

1. Öffnen Sie das IIS-Snap-In über die Verwaltungstools. Sie verfügen nun über einen FTP-Sites-Ordner unter dem Computernamenknoten.
2. Erweitern Sie FTP-Standorte.
3. Klicken Sie mit der rechten Maustaste auf den Standardmäßigen 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 "c:/inetpub/wwwroot/User1 " für den Pfad 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 auf das virtuelle Verzeichnis "User1 " unter "Ftp-Standardwebsite", 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 "Ftp-Standardwebsite" , und wählen Sie "Eigenschaften" aus.
10. Deaktivieren Sie auf der Registerkarte "Sicherheitskonten " die Option "Anonyme Verbindungen zulassen".
11. Klicken Sie im Dialogfeld auf "Ja ", in dem Sie gefragt werden, ob Sie den Vorgang fortsetzen 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 der Internet-Informationsdienste.

Webprojekt erstellen

1. Öffnen Sie Visual Studio 2005.
2. Wählen Sie im Menü "Datei " die Option "Neue Website" aus.
3. Wählen Sie im Dropdown-Menü StandortFTP aus.
4. Klicken Sie auf "Durchsuchen".
5. Geben Sie "localhost " in das Textfeld "Server " ein.
6. Geben Sie "User1 " in das Textfeld "Verzeichnis" ein.
7. Klicken Sie auf Öffnen. Der FTP-Speicherort wird in das Dialogfeld "Neue Website" eingegeben.
8. Klicke auf OK.
9. Deaktivieren Sie die Option "Anonyme Anmeldung " 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 im Solution Explorer angezeigt.)
11. Wählen Sie im Menü " Erstellen " die Option "Website erstellen " oder "Projektmappe erstellen" aus.
12. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf Default.aspx, und wählen Sie "Im Browser anzeigen" aus.
13. Geben Sie http://localhost/user1 im Dialogfeld "Website-URL erforderlich" die URL ein, und klicken Sie auf "OK".

Öffnen von Webprojekten

Das Öffnen von Webprojekten ähnelt dem Erstellen von Projekten. In den folgenden Abschnitten werden Bereiche hervorgehoben, die Sie beim Arbeiten in der IDE beachten sollten. Außerdem wird die Arbeit mit Webprojekten mithilfe von HTTP und FTP behandelt.

Um ein Webprojekt zu öffnen, wählen Sie im Menü "Datei" die Option "Website öffnen" aus. Sie werden mit dem gleichen Dialogfeld "Speicherort auswählen" aufgefordert, das zuvor behandelt wurde, und Sie haben die gleichen vier Optionen für Sie verfügbar: Dateisystem, lokales IIS, FTP und Remotestandort.

Dateisystem

Wie bereits in diesem Modul angegeben, verwendet Visual Studio keine Projektdatei mehr. Wenn Sie daher eine Website aus dem Dateisystem öffnen möchten, haben Sie tatsächlich die Möglichkeit, einen beliebigen Ordner auszuwählen, auch wenn der von Ihnen ausgewählte Ordner ursprünglich in Visual Studio nicht als Webprojekt erstellt wurde. Sie können z. B. den Ordner "Eigene Dokumente" als Website öffnen, und Visual Studio öffnet sie glücklich und zeigt Ihre Dateien wie unten dargestellt an.

Abbildung 6: Meine Dokumente , die als Website geöffnet wurden

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 besteht darin, dass sie verhindert, dass Websites im Dateisystem geschachtelt werden. Betrachten Sie beispielsweise die folgende Verzeichnisstruktur.

Webprojekt bei C:/MyWebSite

Ein weiteres Webprojekt bei 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 über die IIS-Metabasis (lokales IIS) oder mithilfe von FrontPage-Servererweiterungen (Remotewebsite) gelesen.) Wenn geschachtelte Webanwendungen vorhanden sind, werden diese auch 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 deren Inhalt anzuzeigen. Sie können jedoch auf sie doppelklicken, um sie zu öffnen. Wenn Sie dies tun, erhalten Sie ein Dialogfeld, in dem Sie aufgefordert werden, entweder die Webanwendung zu öffnen (und die aktuell geöffnete Lösung zu ersetzen) oder die Webanwendung zu Ihrer aktuellen Lösung hinzuzufügen.

Abbildung 7: Durch Doppelklicken auf ein geschachteltes Anwendungssymbol wird dieses Dialogfeld angezeigt.

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 Eigenschaftenbereich für das Projekt angezeigt und mit dem folgenden Format erstellt.

C:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<Anwendungsname>

Wenn Sie FTP verwenden, muss Visual Studio die Basis-URL für Ihr Projekt angeben, damit Sie sie wie unten gezeigt durchsuchen können. Wenn Sie keine Basis-URL angeben, wird Visual Studio Sie danach fragen, wenn Sie zum ersten Mal versuchen, eine Seite in der Website zu öffnen.

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

Verbesserungen bei der Kompilierung

Das Arbeiten mit Webanwendungen in Visual Studio 2005 ist deutlich schneller als in früheren Versionen. Dies liegt in keinem kleinen Teil an den Änderungen der Kompilierungsarchitektur.

In Visual Studio 2002 und 2003 wurden Webanwendungen in 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 sind als in früheren Versionen.

Eine weitere Erweiterung der Kompilierung ist die neue Option "Build-Seite" im "Build-Menü". Mit diesem Feature kann ein Entwickler nur die aktuelle Seite (selbstverständlich und Abhängigkeiten) neu erstellen, sodass Änderungen schneller kompiliert werden können. Da C# keine Hintergrundkompilierung zum Aktualisieren von IntelliSense usw. bietet, profitieren sie von diesem Feature immens, da intelliSense schnell aktualisiert werden kann, indem einfach eine einzelne Seite neu erstellt wird.

Mit den Build-Eigenschaften für ein Projekt kann man den Typ des Builds konfigurieren, der vor der Ausführung der Startseite stattfindet. Entwickler können die aktuelle Seite nur erstellen, damit Visual Studio nach Codeänderungen schneller mit dem Debuggen von Anwendungen beginnen kann.

Abbildung 9: Startaktion der Buildseite

Eine weitere großartige Erweiterung von Visual Studio und der ASP.NET Architektur befindet sich im 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. Tatsächlich können Sie mit dem Debuggen eines Projekts beginnen, eine neue Klasse hinzufügen, dieser Klasse Code hinzufügen, Ihrer Seite Code hinzufügen, eine neue Instanz dieser Klasse erstellen 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 Videoanleitung zum Bearbeiten-und-Fortfahren-Feature in Visual Studio 2005 anzusehen.

Full-Screen Video öffnen

Die robuste Bearbeitungs- und Fortsetzungsfunktionalität in ASP.NET 2.0 und Visual Studio 2005 ist auf eine Architekturänderung für ASP.NET Anwendungen zurückzuführen. In ASP.NET 1.x wurden anwendungen, die in Visual Studio 2002/2003 erstellt wurden, in eine primäre Assembly kompiliert, die im Ordner "/bin" gespeichert wurde. Alle Klassen, Seiten usw. für die Anwendung wurden in dieser dll kompiliert. Anschließend würde ASP.NET zur Laufzeit alle Steuerelemente, Markups und ASP.NET Code in Seiten kompilieren und diese DLLs in den temporären Ordner ASP.NET kopieren.

In Visual Studio 2005 mit ASP.NET 2.0 wurden die beiden oben beschriebenen Kompilierungsmodelle (eine für Visual Studio und eine für ASP.NET zur Laufzeit) mit einem gemeinsamen Kompilierungsmodell zusammengeführt. Das bedeutet, dass alle Kompilierungsprobleme jetzt während der Entwicklungsphase und nicht zur Laufzeit abgefangen werden. Es ermöglicht außerdem Unterstützung für Designer und IntelliSense bei Funktionen wie Benutzersteuerelementen und Masterseiten.

Klicken Sie hier, um eine Videoanleitung zur Designerunterstützung für Benutzersteuerelemente anzusehen.

Full-Screen Video öffnen

Eine weitere Verbesserung des Visual Studio-Kompilierungsmodells ist das Feature "Website veröffentlichen". Da das Feature "Veröffentlichen" die Website vorab kompiliert, können Entwickler die zusätzliche Leistung genießen, ohne dass sie bei Bedarf kompiliert werden muss. Außerdem wird der gesamte Quellcode im Ordner "App/_Code" in eine DLL vorkompiliert, sodass kein Quellcode bereitgestellt werden muss.

Abbildung 10: Das Dialogfeld "Website veröffentlichen"

Wenn Sie eine Website veröffentlichen, werden die vorkompilierten Dateien wie unten dargestellt im Ordner "Temporäre ASP.NET Dateien" gespeichert. Dateien mit einer kompilierten Dateierweiterung 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 "Vorkompilierte Website zulassen" aktiviert lassen, werden Markups innerhalb Ihrer Webformulare und Benutzersteuerelemente nicht in eine DLL vorkompiliert, sodass Sie Änderungen nach der Bereitstellung vornehmen können. Wenn Sie das Markup lieber sperren möchten, damit Änderungen an den bereitgestellten Inhalten nicht zulässig sind, deaktivieren Sie dieses Kontrollkästchen.

Mit dem Kontrollkästchen "Feste Benennung verwenden" und "Assemblys für einzelne Seiten " können Sie die Batchkompilierung deaktivieren, sodass jede Seite in einer assembly mit fester Bezeichnung 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 mit starkem Namen benennen.

Abbildung 11: Vorkompilierte Dateien einer ASP.NET-Anwendung

Verbesserungen bei der Bereitstellung

Wie bei Visual Studio 2002 und 2003 bietet Visual Studio 2005 ein Feature "Projekt kopieren". Das Feature wurde jedoch in Visual Studio 2005 aufgepeppt und heißt jetzt "Website kopieren".

Das Dialogfeld "Website kopieren" wird in einen linken Rahmen und einen rechten Frame unterteilt. Der linke Frame wird als Quellwebsite bezeichnet, und der rechte Frame wird als Remotewebsite bezeichnet. Eine Sache, die einige Entwickler verwirren kann, ist, dass die im richtigen Frame angezeigte Website nicht unbedingt eine Remotewebsite ist. Es kann sich um eine Website im lokalen Dateisystem oder in der lokalen Instanz von IIS sein. Darüber hinaus ist die im linken Frame angezeigte Website nicht unbedingt die Quellwebsite, da das Dialogfeld Ihnen ermöglicht, von der Remotewebsite auf die Quellwebsite zu veröffentlichen.

Wenn Sie ein Projekt auf eine Remotewebsite kopieren, muss 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-Instanz kopieren, sind FrontPage-Servererweiterungen nicht erforderlich.

Klicken Sie hier, um eine Videoanleitung zur Funktion "Website kopieren" anzuzeigen.

Full-Screen Video öffnen

Verbesserungen beim Debuggen

In Visual Studio 2005 wurden vier wichtige Verbesserungen beim Debuggen verbessert.

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

Debuggen als Nichtadministrator

Durch das Hinzufügen des ASP.NET Development Server können Nichtadministratoren problemlos ASP.NET Anwendungen sofort debuggen. Wenn eine ASP.NET Anwendung, die im lokalen Dateisystem ausgeführt wird, gedebuggt wird, startet Visual Studio den ASP.NET Development Server unter dem 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, dieses Attribut vor der Bereitstellung einer Anwendung in der Produktion auf "false " festzulegen, aber da die meisten Entwickler die Folgen des Verlassens des Debug-Attributs auf "true" nicht vollständig verstehen, verlassen sie es einfach as-is.

Das schwerwiegendste Problem beim Setzen des Debug-Attributs auf „true“ besteht darin, dass das Batchkompilierungsmodell von ASP.NET deaktiviert wird. Daher wird jede Seite in eine separate DLL kompiliert. Wenn eine Webanwendung aus Tausenden von Seiten besteht (was keineswegs ungewöhnlich ist), heißt das, dass mehrere tausend kleine DLLs von dieser Anwendung erstellt werden. Während diese DLLs klein sind, werden sie nicht an einen bestimmten Speicherort im Arbeitsspeicher geladen. Daher verursachen sie 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, werden entwickler beim Debuggen einer ASP.NET Anwendung in Visual Studio 2005 aufgefordert, eine web.config Datei mit aktiviertem Debuggen hinzuzufügen. Dadurch entstehen dieselben 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.

Einrichtung und Konfiguration des Remotedebuggings

In Visual Studio 2002/2003 basiert das Remotedebugging auf dem Machine Debug Manager (mdm.exe) und dem vs7jit.exe Prozess. Aus diesem Grund war die Problembehandlung bei Remotedebugging-Problemen für Kunden häufig eine Blackbox und oft auch für den PSS nicht viel besser.

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

Die Remoteanforderung für das Debuggen in Visual Studio 2005 ist ziemlich 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 einfach msvsmon.exe von einer Freigabe ausführen, ohne etwas auf dem Webserver installieren zu müssen.

Wenn Sie msvsmon.exeausführen, wird es sich wahrscheinlich darüber beschweren, dass Ports für das Remotedebugging blockiert werden. Glücklicherweise können Sie die Blockierung der Ports ganz einfach innerhalb des Warndialogfelds aufheben, wie unten dargestellt.

Abbildung 12: Benachrichtigung, dass die Windows-Firewall Remotedebugging blockiert

Sobald Sie die für das Debuggen erforderlichen Ports freigegeben haben, wird der Remotedebugging-Monitor wie unten dargestellt angezeigt. Über diese Schnittstelle können Sie Verbindungen überwachen und Debuggingberechtigungen ganz einfach ändern.

Abbildung 13: Der Remotedebuggingmonitor

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

Übung 2

Remotedebugging mit Visual Studio 2005

In diesem Labor werden Sie durch das Remotedebugging mit Visual Studio 2005 geführt.

Klicken Sie hier, um eine Videoanleitung für dieses Labor zu sehen.

Full-Screen Video öffnen

Diese Übung erfordert zwei Computer, von denen einer Visual Studio 2005 und der andere IIS 5 oder höher ausführt.

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

1. Suchen Sie auf dem Remote-Webserver msvsmon.exe auf dem Entwicklungscomputer mithilfe eines UNC-Pfads und führen Sie es aus.
   Der Standardspeicherort für msvsmon.exe lautet "//server/c$/Program Files/Microsoft Visual Studio 8/Common7/IDE/Remote Debugger/x86".
2. Wenn Sie aufgefordert werden, die Blockierung von Ports für das Remotedebugging aufzuheben, führen Sie dies aus.
3. Öffnen Sie auf dem Entwicklungscomputer die CodeBehind-Datei für Default.aspx; und legen Sie einen Haltepunkt in der Page/_Load-Methode fest.
4. Starten Sie das Debuggen vom Entwicklungscomputer.

Sie sollten den Haltepunkt wie erwartet erreichen.

Starten von 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 eine bequeme Möglichkeit, Webanwendungen zu durchsuchen und zu debuggen, die auf dem Dateisystem ausgeführt werden.

Der ASP.NET Development Server ist ein eingeschränkter Webserver. Es lässt keine Remoteverbindungen zu; es lässt keine Anfragen von einem anderen Benutzer als demjenigen zu, der den Webserver gestartet hat. Es verfügt auch nicht über die Möglichkeit, ASP-Seiten zu bedienen. 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 die WebDev.WebServer.exe Datei unter c:/Windows/Microsoft.NET/Framework/v2.0.////*ausgeführt wird. Im folgenden Dialogfeld werden die verfügbaren Parameter angezeigt.

Abbildung 14