Bereitstellen eines IIS-gehosteten WCF-Diensts
Das Entwickeln und Bereitstellen eines Windows Communication Foundation (WCF)-Diensts, der in Internetinformationsdienste (IIS) gehostet wird, umfasst die folgenden Aufgaben:
Sicherstellen, dass IIS, ASP.NET, WCF und die WCF-Aktivierungskomponente ordnungsgemäß installiert und registriert sind
Erstellen einer neuen IIS-Anwendung oder Wiederverwenden einer vorhandenen ASP.NET-Anwendung.
Erstellen einer SVC-Datei für den WCF-Dienst.
Bereitstellen der Dienstimplementierung für die IIS-Anwendung
Konfigurieren des WCF-Diensts
Eine ausführliche exemplarische Vorgehensweise zur Erstellung eines IIS-gehosteten WCF-Diensts finden Sie unter Gewusst wie: Hosten eines WCF-Diensts in IIS.
Sicherstellen, dass IIS, ASP.NET und WCF ordnungsgemäß installiert und registriert sind
WCF, IIS und ASP.NET müssen installiert sein, damit IIS-gehostete WCF-Dienste einwandfrei funktionieren. Die Installationsverfahren für WCF (als Bestandteil von .NET Framework 3.0), ASP.NET und IIS variieren je nach verwendeter Betriebssystemversion. Weitere Informationen über das Installieren von WCF und .NET Framework 3.0 finden Sie unter Microsoft .NET Framework 4 (Web Installer). Anweisungen zum Installieren von IIS finden Sie unter Installieren von IIS.
Beim Installationsprozess für .NET Framework 3.0 wird WCF automatisch für IIS registriert, wenn IIS bereits auf dem Computer installiert ist. Wenn IIS nach .NET Framework 3.0 installiert wird, ist ein zusätzlicher Schritt erforderlich, um WCF für IIS und ASP.NET zu registrieren. Gehen Sie hierzu je nach Betriebssystem wie folgt vor:
Windows XP SP2 und Windows Server 2003: Verwenden Sie das Tool ServiceModel Registration-Tool (ServiceModelReg.exe), um WCF für IIS zu registrieren. Geben Sie zu diesem Zweck an der Eingabeaufforderung den Befehl ServiceModelReg.exe /i /x ein.
Windows Vista: Installieren Sie die Unterkomponente "Windows Communication Foundation-Aktivierungskomponenten" von .NET Framework 3.0. Klicken Sie hierzu in der Systemsteuerung auf Software und anschließend auf Windows-Komponenten hinzufügen/entfernen. Dadurch wird der Assistent für Windows-Komponenten aktiviert.
Abschließend müssen Sie sich sicherstellen, dass ASP.NET für die Verwendung von .NET Framework Version 4.0 konfiguriert ist. Führen Sie hierzu das Tool ASPNET_Regiis mit der Option –i aus. Weitere Informationen finden Sie unter ASP.NET IIS-Registrierungstool
Erstellen einer neuen IIS-Anwendung oder Wiederverwenden einer vorhandenen ASP.NET-Anwendung
IIS-gehostete WCF-Dienste müssen sich innerhalb einer IIS-Anwendung befinden. Sie können eine neue IIS-Anwendung erstellen, um ausschließlich WCF-Dienste zu hosten. Alternativ können Sie einen WCF-Dienst in einer vorhandenen Anwendung bereitstellen, die bereits ASP.NET 2.0-Inhalt hostet (wie beispielsweise ASPX-Seiten und ASP.NET-Webdienste [ASMX]). Weitere Informationen über über diese Optionen finden Sie in den Abschnitten "WCF parallel zu ASP.NET hosten" und "WCF-Dienste im ASP.NET-Kompatibilitätsmodus hosten" unter WCF-Dienste und ASP.NET.
Beachten Sie, dass IIS 6.0 und höhere Versionen in regelmäßigen Abständen eine isolierte objektorientierte Programmierungsanwendung neu starten. Der Standardwert beträgt 1740 Minuten. Der höchstmögliche Wert sind 71.582 Minuten. Dieser Neustart kann deaktiviert werden. Weitere Informationen über zu dieser Eigenschaft finden Sie unter PeriodicRestartTime.
Erstellen einer SVC-Datei für den WCF-Dienst
In IIS gehostete WCF-Dienste werden in der IIS-Anwendung als spezielle Inhaltsdateien (SVC-Dateien) dargestellt. Dieses Modell ähnelt der Art und Weise, wie ASMX-Seiten in einer IIS-Anwendung als ASMX-Dateien dargestellt werden. Eine SVC-Datei enthält eine WCF-spezifische Verarbeitungsdirektive (@ServiceHost), die es der WCF-Hostinfrastruktur ermöglicht, gehostete Dienste als Reaktion auf eingehende Nachrichten zu aktivieren. Die gebräuchlichste Syntax für eine SVC-Datei befindet sich in der folgenden Anweisung:
<% @ServiceHost Service="MyNamespace.MyServiceImplementationTypeName" %>
Sie besteht aus der @ServiceHost-Direktive und einem einzelnen Attribut: Service. Der Wert des Service-Attributs ist der CLR-Typname (Common Language Runtime) der Dienstimplementierung. Die Verwendung dieser Direktive ist praktisch mit der Erstellung eines Diensthosts mithilfe des folgenden Codes gleichzusetzen:
new ServiceHost( typeof( MyNamespace.MyServiceImplementationTypeName ) );
Zudem kann eine zusätzliche Hostkonfiguration vorgenommen werden, indem z. B. eine Liste mit Basisadressen für den Dienst erstellt wird. Sie können auch eine benutzerdefinierte ServiceHostFactory verwenden, um die Direktive zur Verwendung mit benutzerdefinierten Hostlösungen zu erweitern. Die IIS-Anwendungen, die WCF-Dienste hosten, sind nicht für die Verwaltung der Erstellung und der Lebensdauer von ServiceHost-Instanzen verantwortlich. Die verwaltete WCF-Hostinfrastruktur erstellt die notwendige ServiceHost-Instanz dynamisch, sobald die erste Anforderung für die SVC-Datei empfangen wird. Die Instanz wird erst freigegeben, wenn sie entweder explizit durch Code geschlossen oder die Anwendung wiederverwendet wird.
Weitere Informationen über über die Syntax für SVC-Dateien finden Sie unter @ServiceHost.
Bereitstellen der Dienstimplementierung für die IIS-Anwendung
In IIS gehostete WCF-Dienste verwenden das gleiche dynamische Kompilierungsmodell wie ASP.NET 2.0. Wie bei ASP.NET können Sie den Implementierungscode für IIS-gehostete WCF-Dienste auf unterschiedliche Weise an verschiedenen Speicherorten folgendermaßen bereitstellen:
Als vorkompilierte DLL im globalen Assemblycache (GAC) oder im \bin-Verzeichnis der Anwendung. Vorkompilierte Binärdateien werden erst aktualisiert, wenn eine neue Version der Klassenbibliothek bereitgestellt wird.
Als nichtkompilierte Quelldateien im \App_Code-Verzeichnis der Anwendung. Quelldateien in diesem Verzeichnis werden dynamisch angefordert, wenn die erste Anforderung der Anwendung verarbeitet wird. Änderungen an Dateien im \App_Code-Verzeichnis führen dazu, dass die gesamte Anwendung wiederverwendet und neu kompiliert wird, wenn die nächste Anforderung empfangen wird.
Als nichtkompilierter Code, der direkt in die SVC-Datei eingefügt wird. Implementierungscode befindet sich zudem inline in der SVC-Datei, nach der @ServiceHost-Direktive. Änderungen an Inlinecode führen dazu, dass die Anwendung wiederverwendet und neu kompiliert wird, wenn die nächste Anforderung empfangen wird.
Weitere Informationen über über das ASP.NET 2.0-Kompilierungsmodell finden Sie unter Übersicht über die ASP.NET-Kompilierung (Seite möglicherweise in englischer Sprache).
Konfigurieren des WCF-Diensts
IIS-gehostete WCF-Dienste speichern ihre Konfiguration in der Web.config-Datei der Anwendung. IIS-gehostete Dienste verwenden die gleichen Konfigurationselemente und die gleiche Syntax wie WCF-Dienste, die außerhalb von IIS gehostet werden. Jedoch gelten die folgenden Einschränkungen nur für die IIS-Hostumgebung:
Basisadressen für IIS-gehostete Dienste
Anwendungen, die WCF-Dienste außerhalb von IIS hosten, können die Basisadresse der von ihnen gehosteten Dienste steuern, indem sie einen Satz Basisadressen-URIs an den ServiceHost-Konstruktor übergeben oder ein <host>-Element in der Konfiguration des Diensts bereitstellen. Dienste, die in IIS gehostet werden, können ihre Basisadressen nicht steuern. Die Basisadresse eines IIS-gehosteten Diensts ist die Adresse seiner SVC-Datei.
Endpunktadressen für IIS-gehostete Dienste
Wenn ein Dienst in IIS gehostet wird, werden Endpunktadressen als relativ zur Adresse der SVC-Datei betrachtet, die den Dienst darstellt. Beispiel: Die Basisadresse eines WCF-Diensts ist https://localhost/Application1/MyService.svc und die Endpunktkonfiguration folgendermaßen:
<endpoint address="anotherEndpoint" .../>
Dadurch wird ein Endpunkt bereitgestellt, der unter "https://localhost/Application1/MyService.svc/anotherEndpoint" erreichbar ist.
Ähnlich stellt das Endpunktkonfigurationselement, das eine leere Zeichenfolge als relative Adresse verwendet, einen Endpunkt bereit, der unter https://localhost/Application1/MyService.svc (der Basisadresse) erreichbar ist.
<endpoint address="" ... />
Sie müssen immer relative Endpunktadressen für IIS-gehostete Dienstendpunkte verwenden. Durch die Angabe einer vollständig qualifizierten Endpunktadresse (z. B. https://localhost/MyService.svc) kann es zu Fehlern bei der Bereitstellung des Diensts kommen, wenn die Endpunktadresse nicht auf die IIS-Anwendung verweist, die den Dienst hostet, der den Endpunkt verfügbar macht. Durch die Verwendung relativer Endpunktadressen für gehostete Dienste werden diese potenziellen Konflikte vermieden.
Verfügbare Transporte
In IIS 5.1 und IIS 6.0 gehostete WCF-Dienste sind auf die Verwendung der HTTP-basierten Kommunikation beschränkt. Auf diesen IIS-Plattformen führt das Konfigurieren eines gehosteten Diensts für die Verwendung einer Nicht-HTTP-Bindung zu einem Fehler während der Dienstaktivierung. Die von IIS 7.0 unterstützten Transporte umfassen HTTP, Net.TCP, Net.Pipe, Net.MSMQ und msmq.formatname für die Abwärtskompatibilität mit bestehenden MSMQ-Anwendungen.
HTTP-Transportsicherheit
IIS-gehostete WCF-Dienste können die http-Transportsicherheit nutzen (beispielsweise HTTPS- und HTTP-Authentifizierungsschemata wie Basic, Digest und die integrierte Windows-Authentifizierung), sofern das virtuelle IIS-Verzeichnis, das den Dienst enthält, diese Einstellungen unterstützt. Die HTTP-Transportsicherheitseinstellungen der Bindung eines gehosteten Endpunkts müssen mit den Transportsicherheitseinstellungen im virtuellen IIS-Verzeichnis identisch sein, in dem sie enthalten ist.
Ein WCF-Endpunkt, der zur Verwendung von HTTP-Digestauthentifizierung konfiguriert wurde, muss beispielsweise in einem virtuellen IIS-Verzeichnis enthalten sein, dessen Konfiguration ebenfalls die HTTP-Digestauthentifizierung zulässt. Kombinationen von IIS-Einstellungen und WCF-Endpunkteinstellungen ohne Entsprechung führen während der Dienstaktivierung zu einem Fehler.
Siehe auch
Konzepte
Hosten in Internetinformationsdiensten
Empfohlene Vorgehensweisen für das Hosten in Internetinformationsdiensten