Freigeben über

Bereitstellen eines IIS-gehosteten WCF-Diensts

  • Artikel

Das Entwickeln und Bereitstellen eines Windows Communication Foundation (WCF)-Diensts, der in Internetinformationsdiensten (IIS) gehostet wird, umfasst die folgenden Aufgaben:

  • Sicherstellen, dass IIS, WCF und die WCF-Aktivierungskomponente ordnungsgemäß installiert und registriert sind
  • Erstellen einer neuen IIS-Anwendung oder Verwenden 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 und WCF ordnungsgemäß installiert und registriert sind

Sowohl WCF als auch IIS muss installiert sein, damit IIS-gehostete WCF-Dienste einwandfrei funktionieren. Die Vorgehensweise zur Installation von WCF (als Teil von .NET Framework 3.0) und IIS variiert je nach verwendeter Betriebssystemversion. Weitere Informationen zur Installation von WCF und .NET Framework 3.0 finden Sie unter Microsoft .NET Framework 3.0 Redistributable Package (möglicherweise in englischer Sprache). Anweisungen zum Installieren von IIS finden Sie unter Installieren von IIS (Seite möglicherweise in englischer Sprache).

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 "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.

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 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 zu dieser Eigenschaft finden Sie unter PeriodicRestartTime (möglicherweise in englischer Sprache).

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 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 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