Hosting di oggetti remoti in Internet Information Services (IIS)

Questo argomento è specifico di una tecnologia legacy mantenuta per una questione di compatibilità con le applicazioni esistenti di versioni precedenti e non è consigliato per il nuovo sviluppo. Le applicazioni distribuite devono ora essere sviluppate utilizzando  Windows Communication Foundation (WCF).

Per ospitare un oggetto remoto in IIS (Internet Information Services) è necessario configurarlo. Ciò viene di norma fatto all'interno di un file di configurazione o livello di codice nel codice dell'applicazione host. Quando un oggetto remoto è ospitato in IIS è possibile sia inserire le informazioni di configurazione in un file Web.config o configurare l'oggetto remoto a livello di codice nel metodo Application_Start nel file Global.asax.

Per utilizzare un file di configurazione per configurare un oggetto remoto, eseguire le operazioni seguenti:

• Inserire le informazioni di configurazione nel file Web.config nella directory virtuale IIS che si è scelto di utilizzare.

• Posizionare l'implementazione del tipo utilizzabile in remoto nella directory \bin (o utilizzare lo strumento Global Assembly Cache (Gacutil.exe) per posizionarlo nella Global Assembly Cache).

Quando si specifica un file Web.config, gli elementi seguenti non sono supportati:

• Specificare un nome applicazione. Il nome della directory virtuale diventa il nome dell'applicazione.

• Utilizzare l'elemento <debug> in un file Web.config utilizzato per la configurazione .NET Remoting.

• Utilizzare un canale diverso da HttpChannel.

• Utilizzare il file Web.config e l'elemento <client> per configurare automaticamente l'applicazione Web client. Se si vuole utilizzare IIS come client .NET Remoting, sarà necessario chiamare RemotingConfiguration.Configure nel metodo Application_Start nel file Global.asax.

Il file Web.config contiene ancora le informazioni di base sul tipo che il sistema deve conoscere, ma alcune dichiarazioni devono essere modificate leggermente per adattarsi all'ambiente host. Ad esempio, si può configurare in maniera personalizzata uno specifico HttpChannel, ma non bisogna specificare una porta per il canale. Se ASP.NET crea un altro dominio applicazione per gestire il caricamento, la configurazione remota farà sì che il nuovo dominio applicazione resti in attesa nuovamente sulla stessa porta, generando un'eccezione. Ad esempio, un file Web.config per un oggetto remoto .NET ospitato in IIS potrebbe essere simile all'esempio di codice seguente. Non è necessario includere le righe di configurazione di canale in questo caso, salvo impostare le proprietà del canale (in questo caso, la proprietà 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>

Nota:
Non specificare una porta per i canali elencati qui. Se si vuole che l'applicazione resti in attesa su una porta specifica, utilizzare Gestione servizi Internet per specificare che IIS è in attesa su quella porta. Il canale che si configura viene utilizzato automaticamente per la gestione di richieste remote inviate a quella porta.

È necessario avere un URI (Uniform Resource Identifier) dell'oggetto che termina in .rem o .soap per ospitare oggetti attivati dal server (ovvero, <wellknown>) in IIS. Per altri domini di applicazioni host non è previsto un simile requisito. Per utilizzare lo strumento Soapsuds (Soapsuds.exe) per generare metadati per un oggetto attivato dal server ospitato in IIS, l'URL da passare come argomento a Soapsuds.exe è la seguente:

http://< Computer >:< Porta >/< DirVirt >/< URIoggetto >?wsdl

Per oggetti attivati dal client ospitati in IIS o in qualsiasi altro dominio applicazione, non è necessario un URI di oggetto in qualsiasi forma. L'URL da passare come argomento a Soapsuds.exe è la seguente:

http://< Computer >:< Porta >/< DirVirt >/RemoteApplicationMetadata.rem?wsdl

La configurazione a livello di codice in IIS viene eseguita utilizzando la pagina Global.asax. Nell'esempio seguente è mostrata la stessa configurazione del file di configurazione mostrato in precedenza, ma viene utilizzato il file 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);
} 

Le voci seguenti devono essere inserite nel file Web.config per assicurarsi che venga fatto riferimento agli assembly obbligatori:

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

Per un esempio completo, vedere Esempio di .NET Remoting: hosting in Internet Information Services (IIS).

Utilizzo di certificati SSL con .NET Remoting

I certificati identificano un computer specifico, il cui nome risiede nel nome comune del certificato. Tuttavia, è facile modificare il nome di un computer o utilizzare "localhost" nei file di configurazione client, cosa che crea una mancata corrispondenza tra il client e il nome comune presente nel certificato server. In .NET Framework versione 1.0, questa mancata corrispondenza viene ignorata, e la chiamata viene richiamata sul server.

A partire dalla versione 1.1 di .NET Framework, questa mancata corrispondenza genera l'eccezione seguente: "System.Net.WebException: Connessione sottostante chiusa: Impossibile stabilire una relazione di trust con il server remoto." Se non si è in grado di configurare il client .NET Remoting per l'utilizzo del nome comune del certificato, è possibile eseguire l'override della mancata corrispondenza utilizzando le impostazioni seguenti nel file di configurazione dell'applicazione client:

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

Per fare in modo che il client trascuri a livello di codice la mancata corrispondenza del nome di certificato, il client deve creare un'istanza di una classe che implementa l'interfaccia ICertificatePolicy e implementa CheckValidationResult per restituire true se il valore certificateProblem è 0x800c010f. È necessario registrare quindi l'oggetto con l'oggetto System.Net.ServicePointManager passando l'oggetto alla proprietà ServicePointManager.CertificatePolicy. Nel codice seguente viene illustrata un'implementazione di 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; 
   }
}

Nel codice seguente viene registrata un'istanza della classe precedente con System.Net ServicePointManager.

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

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

Autenticazione in applicazioni .NET Remoting ospitate in IIS

Nella tabella seguente sono descritte le impostazioni di configurazione che abilitano certi tipi di comportamento di autenticazione in .NET Remoting quando il servizio è ospitato in IIS (Internet Information Services).

Vedere anche

Riferimento

Schema delle impostazioni remote

Concetti

URL di attivazione
Configurazione di applicazioni remote
Esempio di .NET Remoting: hosting in Internet Information Services (IIS)