Hosten von Remoteobjekten in Internetinformationsdiensten (IIS)

Dieses Thema bezieht sich auf eine veraltete Technologie, die zum Zwecke der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten wird und nicht für die neue Entwicklung empfohlen wird. Verteilte Anwendungen sollten jetzt mit  Windows Communication Foundation (WCF) entwickelt werden.

Um ein Remoteobjekt in Internetinformationsdiensten (IIS) zu hosten, müssen Sie das Remoteobjekt konfigurieren. Normalerweise erfolgt dies entweder innerhalb einer Konfigurationsdatei oder programmgesteuert innerhalb des Hostinganwendungscodes. Wenn ein Remoteobjekt innerhalb von IIS gehostet wird, können Sie die Konfigurationsinformationen in eine Web.config-Datei stellen oder das Remoteobjekt in der Application_Start-Methode in der Datei Global.asax programmgesteuert konfigurieren.

Gehen Sie wie folgt vor, um eine Konfigurationsdatei zum Konfigurieren eines Remoteobjekts zu verwenden:

• Stellen Sie die Konfigurationsinformationen im ausgewählten virtuellen IIS-Verzeichnis in die Datei Web.config.

• Stellen Sie die Implementierung des remotefähigen Typs in das Verzeichnis \bin (oder verwenden Sie das Globale Assemblycache-Tool (Gacutil.exe), um sie in den globalen Assemblycache zu stellen).

Bei Angabe der Datei Web.config wird Folgendes nicht unterstützt:

• Bei Angabe eines Anwendungsnamens wird der Name des virtuellen Verzeichnisses zum Anwendungsnamen.

• Die Verwendung des <debug>-Elements in einer Web.config-Datei, die für die .NET-Remotekonfiguration verwendet wird.

• Die Verwendung eines anderen Channels als HttpChannel.

• Verwenden Sie die Datei Web.config und das <client>-Element, um die Clientwebanwendung automatisch zu konfigurieren. Wenn IIS als Remoteclient verwendet werden soll, müssen Sie RemotingConfiguration.Configure in der Application_Start-Methode innerhalb der Datei Global.asax aufrufen.

Die Datei Web.config enthält immer noch die Basisinformationen über den Typ, den das System kennen muss. Zur Anpassung der Hostingumgebung müssen ein paar Deklarationen jedoch ein wenig geändert werden. Sie können z. B. eine benutzerdefinierte Konfiguration eines bestimmten HttpChannel vornehmen, dürfen aber keinen Anschluss für den Channel angeben. Sollte ASP.NET eine weitere Anwendungsdomäne zur Verarbeitung der Last erstellen, versucht diese neue Anwendungsdomäne aufgrund der Remotekonfiguration, den selben Anschluss erneut zu überwachen und löst daraufhin eine Ausnahme aus. Die Datei Web.config für ein IIS-gehostetes .NET-Remoteobjekt können wie im folgenden Codebeispiel gezeigt aussehen. Hier ist es nicht erforderlich, die Zeilen für die Channelkonfiguration einzufügen, es sei denn, Sie möchten die Channeleigenschaften (in diesem Fall die priority-Eigenschaft) festlegen.

<configuration>
   <system.runtime.remoting>
      <application>
         <service>
            <wellknown 
               mode="Singleton" 
               type="ServiceClass, ServiceClassAssemblyName"
                objectUri="ServiceClass.rem"
            />
         </service>
         <channels>
            <channel 
               name="MyChannel" 
               priority="100" 
               ref="http"
            />
         </channels>
      </application>
   </system.runtime.remoting>
</configuration>

Hinweis:
Geben Sie keinen Anschluss für hier aufgelistete Channels an. Wenn die Anwendung einen bestimmten Anschluss überwachen soll, geben Sie mit dem Internetdienste-Manager an, dass IIS diesen Anschluss überwachen soll. Der konfigurierte Channel wird automatisch verwendet, um auf diesem Anschluss übermittelte Remoteanforderungen zu verarbeiten.

Um vom Server aktivierte Objekte (d. h. <wellknown>-Objekte) innerhalb von IIS erfolgreich zu hosten, müssen Sie über einen Objekt-URI (Uniform Resource Identifier) verfügen, der auf REM oder SOAP endet. Für andere Hostanwendungsdomänen ist dies nicht erforderlich. Wenn das Soapsuds-Tool (Soapsuds.exe) zum Generieren von Metadaten für ein vom Server aktiviertes, in IIS gehostetes Objekt verwendet werden soll, lautet die URL, die als Argument an Soapsuds.exe übergeben werden soll, wie folgt:

http://< Computer >:< Port >/< VirtDir >/< ObjectURI >?wsdl

Für vom Client aktivierte Objekte, die in IIS oder in einer anderen Anwendungsdomäne gehostet werden, benötigen Sie keinen URI. Die URL, die als Argument an Soapsuds.exe übergeben werden soll, lautet wie folgt:

http://< Computer >:< Port >/< VirtDir >/RemoteApplicationMetadata.rem?wsdl

Die programmgesteuerte Konfiguration in IIS erfolgt mit der Seite Global.asax. Das folgende Beispiel zeigt die gleiche Konfiguration wie die oben gezeigte Konfigurationsdatei. Bei dieser Konfiguration wird jedoch die Datei Global.asax verwendet.

<%@ Application Language="VB" %>
<%@ Assembly Name="Server" %>
<%@ Import Namespace="System.Runtime.Remoting" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels.Http" %>
<%@ Import Namespace="Server" %>

Sub Application_Start()
   Dim props = New Hashtable() As IDictionary
   props("name") = "MyChannel" 
   props("priority") = "100" 
   ' Nothing entries specify the default formatters.
   Dim channel As New HttpChannel( _
      props, _
      Nothing, _
      Nothing _
   )
   ChannelServices.RegisterChannel(channel)
   Dim WKSTE As New WellKnownServiceTypeEntry( _
      GetType(ServiceClass), _
      "HttpService", _
      WellKnownObjectMode.SingleCall
   )
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE)
End Sub

<%@ Application Language="C#" %>
<%@ Assembly Name="Server" %>
<%@ Import Namespace="System.Runtime.Remoting" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels" %>
<%@ Import Namespace="System.Runtime.Remoting.Channels.Http" %>
<%@ Import Namespace="Server" %>
void Application_Start(){
   IDictionary props = new Hashtable();
   props["name"] = "MyChannel";
   props["priority"] = "100";
   // Null entries specify the default formatters.
   HttpChannel channel = new HttpChannel(
      props, 
      null, 
      null
   );
   ChannelServices.RegisterChannel(channel);
   WellKnownServiceTypeEntry WKSTE = new WellKnownServiceTypeEntry(
      typeof(ServiceClass),
      "HttpService", 
      WellKnownObjectMode.SingleCall
   );
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE);
} 

Die folgenden Einträge müssen in die Datei Web.config eingefügt werden, um sicherzustellen, dass auf die erforderlichen Assemblys verwiesen wird.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
      <compilation>
        <assemblies>
          <add assembly="System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </assemblies>
      </compilation>
  </system.web>
</configuration>

Ein vollständiges Beispiel finden Sie unter Remotingbeispiel: Hosting in Internetinformationsdiensten (IIS).

Verwenden von SSL-Zertifikaten mit .NET-Remoting

Zertifikate identifizieren einen bestimmten Computer, dessen Name sich im allgemeinen Namen des Zertifikats befindet. Allerdings kann der Name eines Computers in Clientkonfigurationsdateien problemlos geändert oder "localhost" verwendet werden. Dadurch entsteht ein Konflikt zwischen dem Client und dem allgemeinen Namen im Serverzertifikat. In .NET Framework, Version 1.0, wird dieser Konflikt ignoriert, und der Aufruf erfolgt auf dem Server.

Ab .NET Framework, Version 1.1, löst dieser Konflikt folgende Ausnahme aus: "System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Mit dem Remoteserver konnte keine Vertrauensstellung hergestellt werden". Wenn Sie nicht in der Lage sind, den Remoteclient für die Verwendung des gemeinsamen Zertifikatsnamens zu konfigurieren, können Sie den Konflikt mit den folgenden Einstellungen in der Konfigurationsdatei der Clientanwendung lösen:

<system.net>
   <settings>
      <servicePointManager
         checkCertificateName="true"
      />
   </settings>
</system.net>

Um den Client dazu zu bringen, den Zertifikatnamenskonflikt programmgesteuert zu ignorieren, muss der Client eine Instanz einer Klasse erstellen, die die ICertificatePolicy-Schnittstelle und CheckValidationResult implementiert, damit true zurückgegeben wird, wenn der certificateProblem-Wert 0x800c010f ist. Sie müssen dann das Objekt beim System.Net.ServicePointManager-Objekt registrieren, indem Sie das Objekt an die ServicePointManager.CertificatePolicy-Eigenschaft übergeben. Der folgende Code ist eine Basisimplementierung:

Public Class MyPolicy Implements ICertificatePolicy 
   Public Function CheckValidationResult(srvPoint As ServicePoint, certificate As X509Certificate, request As WebRequest, certificateProblem As Integer) As Boolean
      ' Check for policy common name mismatch. 
       If certificateProblem = 0 Or certificateProblem = &H800b010f Then
         Return True
      Else
         Return False
      EndIf
   End Function
End Class

public class MyPolicy : ICertificatePolicy {
   public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) {
      // Check for policy common name mismatch. 
      if (certificateProblem == 0 || certificateProblem == 0x800b010f)
         return true;
      else
         return false; 
   }
}

Mit dem folgenden Code wird eine Instanz der vorhergehenden Klasse bei System.Net ServicePointManager registriert:

System.Net.ServicePointManager.CertificatePolicy = New MyPolicy()

System.Net.ServicePointManager.CertificatePolicy = new MyPolicy();

Authentifizierung in IIS-gehosteten Remoteanwendungen

Die folgende Tabelle enthält eine Beschreibung der Konfigurationseinstellungen, die bestimmte Typen des Authentifizierungsverhaltens in .NET-Remoting aktivieren, wenn der Dienst in Internetinformationsdiensten (IIS) gehostet wird.

Siehe auch

Verweis

Schema für Remoteeinstellungen

Konzepte

Aktivierungs-URLs
Konfiguration von Remoteanwendungen
Remotingbeispiel: Hosting in Internetinformationsdiensten (IIS)