Freigeben über

Hosten von Remoteobjekten in Internetinformationsdienste

  • Artikel

Wenn Sie den Remotetyp mit Internetinformationsdienste (Internet Information Services, IIS) hosten, kann das Remotingsystem für den remotefähigen Typ nicht direkt im Hostprozess programmgesteuert konfiguriert werden, da die Hostanwendungsdomänen von IIS und ASP.NET erstellt werden. Sie können jedoch mit der Datei Global.asax einen Großteil der programmgesteuerten Konfiguration nachvollziehen, die auch in anderen Typen von Anwendungsdomänen möglich ist. Führen Sie folgende Schritte aus, wenn Sie eine Konfigurationsdatei für die Remotekonfiguration verwenden möchten und IIS der Hostprozess ist:

  • Fügen Sie die Konfigurationsinformationen der Datei Web.config im zu verwendenden virtuellen IIS-Verzeichnis hinzu.

  • Legen Sie die Implementierung des remotefähigen Typs im Verzeichnis \bin ab (oder verwenden Sie das GAC-Tool ("Gacutil.exe"), um die Implementierung im globalen Assemblycache (GAC) zu speichern).

Darüber hinaus ist Folgendes nicht möglich:

  • Angeben eines Anwendungsnamens beim Hosten in IIS. Der Name des virtuellen Verzeichnisses wird als Anwendungsname verwendet.

  • Verwenden des <debug>-Elements in einer Datei Web.config, die für die .NET Remoting-Konfiguration verwendet wird.

  • Verwenden eines anderen Channels als HttpChannel.

  • Verwenden der Datei Web.config und des <client>-Elements zum automatischen Konfigurieren der Clientwebanwendung. Wenn IIS als Remoteclient verwendet werden soll, müssen Sie in der Datei Global.asax in der Application_Start-Methode RemotingConfiguration.Configure aufrufen.

Die Konfigurationsdatei für Remoting enthält dann immer noch die grundlegenden Informationen zum Typ, die das System kennen muss, aber einige Deklarationen müssen geringfügig geändert werden, um der Hostumgebung gerecht zu werden. So können Sie z. B. eine bestimmtes HttpChannel-Objekt benutzerdefiniert konfigurieren, sollten aber keinen Port für den Channel festlegen. Wenn nämlich ASP.NET zur Lastenverarbeitung eine andere Anwendungsdomäne erstellt, führt die Remotekonfiguration dazu, dass die neue Anwendungsdomäne versucht, denselben Port erneut zu überwachen, wodurch eine Ausnahme ausgelöst wird. Eine einfache Datei Web.config für einen in IIS gehosteten .NET Remoting-XML-Webdienst könnte z. B. so aussehen, wie im nachfolgenden Codebeispiel dargestellt. Bedenken Sie, dass es in diesem Fall nicht erforderlich ist, die Zeilen für die Channelkonfiguration einzufügen, es sei denn, um die Channeleigenschaften (in diesem Fall die priority-Eigenschaft) an die verwendete Instanz anzufügen.

<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 für hier aufgelistete Channels keinen Port an. Wenn die Anwendung einen bestimmten Port überwachen soll, geben Sie mit dem Internetdienste-Manager an, dass IIS diesen Anschluss überwacht. Der konfigurierte Channel wird automatisch zur Behandlung von an diesen Port gesendeten Remoteanforderungen verwendet.

Um serveraktivierte Objekte (d. h. <wellknown>-Objekte) in IIS erfolgreich zu hosten, muss ein Objekt-URI (Uniform Resource Identifier) mit der Erweiterung REM oder SOAP vorhanden sein. (Für andere Hostanwendungsdomänen gilt diese Anforderung nicht.) Wenn das Soapsuds-Tool ("Soapsuds.exe") zum Generieren von Metadaten für ein in IIS gehostetes, serveraktiviertes Objekt verwendet werden soll, muss der folgende URL als Argument an Soapsuds.exe übergeben werden:

http://<Computer>:<Port>/<VirtuellesVerzeichnis>/<Objekt-URI>?wsdl

Für in IIS oder einer anderen Anwendungsdomäne gehostete, clientaktivierte Objekte ist keinerlei Objekt-URI erforderlich. In diesem Fall muss der folgende URL als Argument an Soapsuds.exe übergeben werden:

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

Die programmgesteuerte Konfiguration in IIS erfolgt unter Verwendung der Global.asax-Seite. Im folgenden Beispiel wird dieselbe Konfiguration wie in der vorangegangenen Konfigurationsdatei dargestellt, jedoch wird hier die Datei Global.asax verwendet.

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

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);
}

Mit anderen Worten können Sie also den Dienst in IIS auf dieselbe Art und Weise hosten wie auch in anderen Arten von Hostanwendungsdomänen. Ein vollständiges Beispiel dazu finden Sie unter Remotingbeispiel: Hosten in Internetinformationsdienste.

Verwenden von SSL-Zertifikaten mit .NET Remoting

Zertifikate identifizieren einen bestimmten Computer, dessen Name im gemeinsamen Namen des Zertifikats enthalten ist. Es ist jedoch leicht möglich, dass der Name eines Computers geändert oder "localhost" in Clientkonfigurationsdateien verwendet wird, wodurch ein Konflikt zwischen dem Clientnamen und dem gemeinsamen Namen im Serverzertikat entsteht. In .NET Framework, Version 1.0, wird dieser Konflikt ignoriert und der Aufruf für den Server durchgeführt.

Seit .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 der Remoteclient nicht für die Verwendung des gemeinsamen Namens des Zertifikats konfiguriert werden kann, kann der Konflikt mit den folgenden Einstellungen in der Konfigurationsdatei der Clientanwendung außer Kraft gesetzt werden.

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

Damit der Client den Konflikt im Zertifikatsnamen programmgesteuert übergehen kann, muss der Client eine Instanz einer Klasse erstellen, die die ICertificatePolicy-Schnittstelle und die CheckValidationResult-Methode implementiert, um true zurückzugeben, wenn 0x800c010f der Wert von certificateProblem ist. Anschließend muss das Objekt beim System.Net.ServicePointManager-Objekt registriert werden, indem das Objekt an die ServicePointManager.CertificatePolicy-Eigenschaft übergeben wird. Der folgende Code stellt eine Basisimplementierung dar.

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 vorherigen Klasse bei System.Net ServicePointManager registriert.

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

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

Authentifizierung in IIS-gehosteten Remoteanwendungen

In der folgenden Tabelle werden die Konfigurationseinstellungen beschrieben, mit denen bestimmte Arten von Authentifizierungsverhalten in .NET Remoting ermöglicht werden, wenn der Dienst in Internetinformationsdienste (Internet Information Services, IIS) gehostet wird.

Gewünschtes Verhalten Konfigurationseinstellungen Kommentare

Der Server authentifiziert den Client bei jedem Aufruf mit den Standardanmeldeinformationen des Clients.

Aktivieren Sie auf dem Server Integrierte Windows-Authentifizierung, und deaktivieren Sie in IIS Anonymer Zugriff.

Legen Sie auf dem Client die Anmeldeinformationen auf die Verwendung von CredentialCache.DefaultCredentials fest.

Dies ist das Standardverhalten in der Version 1.0 von .NET Framework, wenn useDefaultCredentials den Wert true aufweist.

Dieses Verhalten wird in der Version 1.1 von .NET Framework unterstützt, wenn useAuthenticatedConnectionSharing ebenfalls auf false festgelegt ist.

Der Server authentifiziert den Client einmal mit den Standardanmeldeinformationen des Clients, und bei nachfolgenden Aufrufen von diesem Client wird die bereits authentifizierte Verbindung verwendet.

Aktivieren Sie auf dem Server Integrierte Windows-Authentifizierung, und deaktivieren Sie in IIS Anonymer Zugriff.

Legen Sie auf dem Client useDefaultCredentials auf true fest.

Dieses Verhalten wird nur in .NET Framework, Version 1.1 und höher, unterstützt.

Der Server authentifiziert den Client einmal mit benutzerdefinierten oder expliziten Anmeldeinformationen des Clients, und bei nachfolgenden Aufrufen von diesem Client wird die bereits authentifizierte Verbindung verwendet.

Aktivieren Sie auf dem Server Integrierte Windows-Authentifizierung, und deaktivieren Sie in IIS Anonymer Zugriff.

Legen Sie auf dem Client entweder die Anmeldeinformationen auf eine ICredentials-Implementierung fest, oder legen Sie den Benutzernamen, das Kennwort und die Domäne auf explizite Werte fest. In beiden Fällen müssen Sie auch unsafeAuthenticatedConnectionSharing auf true festlegen und einen connectionGroupName-Wert angeben, der einem authentifizierten Benutzer eindeutig zugeordnet ist.

Dieses Verhalten wird nur in .NET Framework, Version 1.1 und höher, unterstützt.

Siehe auch

Referenz

Remoting Settings Schema

Konzepte

Aktivierungs-URLs
Konfiguration von Remoteanwendungen
Remotingbeispiel: Hosten in Internetinformationsdienste