Freigeben über


Hosting von Remoteobjekten in Internet Information Services (IIS)

Wenn Sie den Remotetyp mit Internet-Informationsdienste (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 Remotingkonfiguration 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 Global Assembly Cache-Tool (Gacutil.exe), um die Implementierung im globalen Assemblycache zu speichern).

Darüber hinaus ist Folgendes nicht möglich:

  • Angeben eines Anwendungsnamens bei IIS als Host. 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 Remotingclient 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 über den 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. einen bestimmten HttpChannel benutzerdefiniert konfigurieren, sollten aber keinen Anschluss 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 Anschluss erneut abzufragen, wodurch eine Ausnahme ausgelöst wird. Eine einfache Web.config-Datei 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 anzuhängen.

<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 Anschluss an. Wenn die Anwendung einen bestimmten Anschluss überwachen soll, geben Sie mit dem Internetdienste-Manager an, dass IIS diesen Anschluss überwacht. Der konfigurierte Channel wird automatisch zur Behandlung von an diesen Anschluss 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 gelten diese Voraussetzungen nicht.) Wenn das Soapsuds-Tool (Soapsuds.exe) zum Erzeugen 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>:<Anschluss>/<VirtVerz>/<ObjektURI>?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>:<Anschluss>/<VirtVerz>/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
[C#]
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 finden Sie unter Remotingbeispiel: Hosting in Internet Information Services (IIS).

Verwenden von SSL-Zertifikaten mit .NET Remoting

Zertifikate geben einen bestimmten Computer an, dessen Name im Anzeigenamen des Zertifikats enthalten ist. Es ist jedoch möglich, dass der Name eines Computers geändert oder "localhost" in Clientkonfigurationsdateien verwendet wird, wodurch eine Diskrepanz zwischen Clientname und Anzeigename im Serverzertikat entsteht. In .NET Framework, Version 1.0, wird dieser Übereinstimmungsfehler ignoriert und der Aufruf für den Server durchgeführt.

Ab .NET Framework, Version 1.1, wird durch diesen Übereinstimmungsfehler die folgende Ausnahme ausgelöst: "System.Net.WebException: Die zugrundeliegende Verbindung wurde geschlossen: Mit dem Remoteserver konnte keine Vertrauensstellung hergestellt werden." Wenn der Remotingclient nicht für die Verwendung des Anzeigenamens des Zertifikats konfiguriert werden kann, kann der Übereinstimmungsfehler mit den folgenden Einstellungen in der Konfigurationsdatei der Clientanwendung überschrieben werden.

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

Damit der Client die Diskrepanz 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 der Wert von certificateProblem 0x800c010f 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(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, Integer certificateProblem) As Boolean
      ' Check for policy common name mismatch. 
       If certificationProblem = 0 Or certificateProblem = &H800c010f Then
         Return True
      Else
         Return False
   End Function
End Class
[C#]
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 == 0x800c010f)
         return true;
      else
         return false; 
   }
}

Der folgende Code registriert eine Instanz der vorherigen Klasse beim System.Net ServicePointManager.

System.Net.ServicePointManager.CertificatePolicy = New MyPolicy()
[C#]
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 Internet-Informationsdienste (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 Anonyme Anmeldung.

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 true ist.

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 Anonyme Anmeldung.

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 Anonyme Anmeldung.

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

Aktivierungs-URLs | Konfiguration | Schema für Remoteeinstellungen | Remotingbeispiel: Hosting in Internet Information Services (IIS)