Partager via

Hébergement d'objets distants dans les Services Internet (IIS)

  • Article

Cette rubrique est spécifique à la technologie héritée assurant la compatibilité descendante avec des applications existantes et n'est pas recommandée en cas de nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF).

Pour héberger un objet distant dans les Services Internet (IIS), vous devez d'abord le configurer. Généralement, vous devez soit passer par un fichier de configuration, soit utiliser un programme dans le code de l'application d'hébergement. Lorsqu'un objet distant est hébergé dans IIS, vous pouvez soit placer les informations de configuration dans un fichier Web.config, soit configurer par programme l'objet distant dans la méthode Application_Start du fichier Global.asax.

Pour utiliser un fichier de configuration afin de configurer un objet distant, procédez comme suit :

  • Placez vos informations de configuration dans le fichier Web.config dans le répertoire virtuel IIS que vous avez choisi.

  • Placez votre implémentation de type accessible à distance dans le répertoire \bin (ou utilisez l'outil Global Assembly Cache (Gacutil.exe) pour la placer dans le Global Assembly Cache).

Lorsque vous spécifiez un fichier Web.config, les éléments suivants ne sont pas pris en charge :

  • Si vous spécifiez un nom d'application, le nom du répertoire virtuel devient le nom de votre application.

  • Utiliser un élément <debug> dans un fichier Web.config utilisé pour la configuration de .NET Remoting.

  • Utiliser un autre canal que HttpChannel.

  • Utiliser le fichier Web.config et l'élément <client> pour configurer automatiquement votre application Web cliente. Si vous souhaitez utiliser IIS comme un client de communication à distance, vous devez appeler RemotingConfiguration.Configure dans la méthode Application_Start dans le fichier Global.asax.

Le fichier Web.config contient encore les informations de base relatives à votre type que le système doit connaître, mais certaines déclarations doivent être légèrement modifiées pour s'adapter à l'environnement d'hébergement. Par exemple, vous pouvez configurer de manière personnalisée un HttpChannel particulier, mais vous ne devez pas spécifier de port pour le canal ; si ASP.NET crée un autre domaine d'application pour gérer la charge, ce nouveau domaine d'application va essayer d'écouter sur le même port et va donc lever une exception, en raison de la configuration de communication à distance. Par exemple, un fichier Web.config pour un objet distant .NET hébergé par IIS peut ressembler à l'exemple de code suivant. Il n'est pas nécessaire d'inclure les lignes de la configuration du canal dans ce cas, sauf pour définir les propriétés de canal (ici, la propriété priority ).

<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>
y0hedwet.note(fr-fr,VS.100).gifRemarque :
Ne spécifiez de port pour aucun des canaux répertoriés ici. Si vous souhaitez que votre application écoute sur un port particulier, utilisez le Gestionnaire des services Internet pour spécifier qu'IIS écoute sur ce port. Le canal que vous configurez est utilisé automatiquement pour gérer les demandes distantes envoyées sur ce port.

Pour réussir à héberger des objets activés par le serveur (c'est-à-dire <wellknown>) dans IIS, vous devez avoir un URI (Uniform Resource Identifier) d'objet qui se termine en .rem ou .soap. Cette obligation ne s'applique pas pour les autres domaines d'application hôtes. Pour utiliser l'outil Soapsuds (Soapsuds.exe) afin de générer des métadonnées pour un objet activé par le serveur hébergé dans IIS, l'URL à passer en tant qu'argument à Soapsuds.exe se présente comme suit :

http://< Ordinateur >:< Port >/< RépVirt >/< URIObjet >?wsdl

Pour les objets activés par le client hébergés dans IIS ou dans tout autre domaine d'application, vous n'avez besoin d'aucun URI d'objet. L'URL à passer en tant qu'argument à Soapsuds.exe se présente comme suit :

http://< Ordinateur >:< Port >/< RépVirt >/RemoteApplicationMetadata.rem?wsdl

La configuration par programme dans IIS s'effectue via la page Global.asax. L'exemple suivant présente la même configuration que le fichier de configuration précédent, mais utilise le fichier Global.asax.

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

Les entrées suivantes doivent être placées dans le fichier Web.config afin de s'assurer que les assemblys requis sont référencés :

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

Pour obtenir un exemple complet, consultez Exemple de communication à distance : hébergement dans les Services Internet (IIS).

Utilisation de certificats SSL avec .NET Remoting

Les certificats identifient un ordinateur spécifique, dont le nom réside dans le nom commun du certificat. Toutefois, il est facile de modifier le nom d'un ordinateur ou d'utiliser « localhost » dans les fichiers de configuration client, ce qui crée une incompatibilité entre le client et le nom commun du certificat du serveur. Dans la version 1.0 du .NET Framework, cette incompatibilité est ignorée et l'appel s'effectue sur le serveur.

À partir de la version 1.1 du .NET Framework version 1.1, cette incompatibilité lève l'exception suivante : « System.Net.WebException : La connexion sous-jacente a été fermée : Impossible d'établir une relation de confiance avec le serveur distant. » Si vous ne parvenez pas à configurer le client de communication à distance de façon à ce qu'il utilise le nom commun du certificat, vous pouvez ignorer l'incompatibilité en ajoutant les paramètres suivants dans le fichier de configuration de votre application cliente :

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

Pour que votre client ignore l'incompatibilité de nom de certificat par programme, il doit créer une instance d'une classe qui implémente l'interface ICertificatePolicy et CheckValidationResult afin de retourner true si la valeur de certificateProblem est 0x800c010f. Vous devez ensuite inscrire l'objet auprès de l'objet System.Net.ServicePointManager en passant l'objet à la propriété ServicePointManager.CertificatePolicy. Le code suivant est une implémentation de base :

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

Le code suivant inscrit une instance de la classe précédente auprès du System.Net ServicePointManager:

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

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

Authentification dans les applications de communication à distance hébergées par IIS

Le tableau suivant décrit les paramètres de configuration qui activent certains types de comportement d'authentification dans .NET Remoting lorsque votre service est hébergé dans les Services Internet (IIS).

Comportement souhaité Paramètres de configuration Commentaires

Le serveur authentifie le client à chaque appel à l'aide des informations d'identification par défaut du client.

Sur le serveur, sélectionnez Authentification Windows intégrée et désélectionnez Accès anonyme dans IIS.

Sur le client, définissez useDefaultCredentials à true.

Il s'agit du comportement par défaut dans la version 1.0 du .NET Framework lorsque useDefaultCredentials a la valeur true.

Ce comportement est pris en charge dans la version 1.1 du .NET Framework si useAuthenticatedConnectionSharing a également la valeur false.

Le serveur authentifie le client une seule fois, à l'aide de ses informations d'identification par défaut ; les appels suivants de ce client utilisent la connexion précédemment authentifiée.

Sur le serveur, sélectionnez Authentification Windows intégrée et désélectionnez Accès anonyme dans IIS.

Sur le client, définissez useDefaultCredentials à true.

Ce comportement n'est pris en charge que dans les versions 1.1 et supérieures du .NET Framework.

Le serveur authentifie le client une seule fois, à l'aide des informations d'identification personnalisées ou explicites du client ; les appels suivants de ce client utilisent la connexion précédemment authentifiée.

Sur le serveur, sélectionnez Authentification Windows intégrée et désélectionnez Accès anonyme dans IIS.

Sur le client, définissez credentials à une implémentation ICredentials ou définissez username, password et domain à des valeurs explicites. Dans tous les cas, vous devez également définir la valeur unsafeAuthenticatedConnectionSharing à true et fournir une valeur connectionGroupName qui corresponde à un seul utilisateur authentifié.

Ce comportement n'est pris en charge que dans les versions 1.1 et ultérieures du .NET Framework.

Voir aussi

Référence

Schéma des paramètres de communication à distance

Concepts

URL d'activation
Configuration d'applications distantes
Exemple de communication à distance : hébergement dans les Services Internet (IIS)