Format für .NET Remoting-Konfigurationsdateien

Veröffentlicht: 01. Nov 2001 | Aktualisiert: 18. Jun 2004

Von Piet Obermeyer

In diesem Artikel wird das von Remotingkonfigurationsdateien verwendete Schema detailliert beschrieben.

Auf dieser Seite

 Hosten von Remoteanwendungen
 Gründe für das Registrieren von Channeln
 Gründe für das Registrieren von Objekten
 Einstellungsschema
 Beschreibung der Elemente

Einführung

Alle Remoteobjekte müssen vor dem Clientzugriff mit dem Remotingframework registriert werden. Während der Registrierung werden dem Framework alle Informationen zur Verfügung gestellt, die zum Aktivieren und Verwalten der Objektlebensdauer erforderlich sind. Die Hauptdaten für die Registrierung sind der Objekttyp, der URI, unter dem sie bereitgestellt wird, die Aktivierungsanforderungen zum Verwalten der Objektlebensdauer sowie die Channel, die zur Verbindungsherstellung mit dem Objekt verwendet werden können.

Auch wenn die programmatische Registrierung ein einfacher Vorgang ist, ist ihre Verwendung für echte Anwendungen, bei denen viele Remoteobjekte in einem Unternehmensnetzwerk verwaltet werden müssen, nicht immer erwünscht. Die Remotingkonfiguration löst dieses Problem, indem ein einfacher Mechanismus zur Objektregistrierung mithilfe von Konfigurationsdateien zur Verfügung gestellt wird, der den Administratoren auch das Feinabstimmen der Remotingeinstellungen ohne erneutes Kompilieren der Anwendungen oder Dienste ermöglicht. In diesem Artikel wird ausführlich beschrieben, wie die Remotingkonfiguration verwendet werden kann. Des Weiteren werden die Elemente der Konfigurationsdatei beschrieben.

Hosten von Remoteanwendungen

Die Objektregistrierung erfolgt normalerweise von einer Hostinganwendung, die erst startet, dann einen oder mehrere Channel mit ChannelServices registriert, anschließend ein oder mehrere Remoteobjekte mit RemotingServices registriert und schließlich wartet, bis sie beendet wird. Wichtig: Die registrierten Channel und Objekte sind nur verfügbar, während der Prozess, über den sie registriert wurden, aktiv ist. Bei Prozessbeendigung werden alle durch diesen Prozess registrierten Channel und Objekte automatisch aus den Remotingdiensten entfernt, in denen sie registriert wurden. Die Configure-Methode bei RemotingConfiguration muss zum Konfigurieren eines Objekts mit einer Konfigurationsdatei aufgerufen werden. Dies kann folgendermaßen auf einfache Weise erreicht werden:

using System; 
using System.IO; 
using System.Runtime.Remoting; 
public class MyHost { 
  public static void Main(String[] args) 
  { 
    if (args.Length == 0) { 
      // Standardkonfiguration durchführen, eine Ausnahme auslösen 
      // oder dem Benutzer Verwendungsinformationen anzeigen 
    } 
    else { 
      RemotingConfiguration.Configure (args[0]); 
    } 
    // Das Programm sollte hier anhalten, bis die 
    // registrierten Objekte nicht mehr erforderlich sind 
  }

Configure lädt die Konfigurationsdatei in den Speicher, analysiert den Inhalt und ruft die relevanten Methoden zum Registrieren der in der Datei beschriebenen Channel und Objekte auf. Es gibt keine Besonderheiten zum Configure-Aufruf. Jeder Host kann die Konfigurationsdatei laden und analysieren, die erforderlichen Informationen extrahieren und das bzw. die Objekte registrieren. Wichtig: Remoting wird beim Laden einer Konfigurationsdatei beim Anwendungsstart nicht konfiguriert.

Gründe für das Registrieren von Channeln

Wird eine Channelinstanz mit dem Framework registriert, überwacht sie Clientanfragen im Protokoll, für das sie entworfen wurde. Wichtig: Channel gehören zu keinem bestimmten Remoteobjekt. Derselbe Channel kann eine beliebige Anzahl von Remoteobjekten bedienen.

Während der Objektregistrierung wird das Remoteobjekt gemarshallt, um einen Objektverweis ObjRef zu erzeugen, der alle für das Aktivieren des und Kommunizieren mit dem Remoteobjekt(s) relevanten Informationen speichert. Da ObjRef zum Erzeugen von TransparentProxy während des Unmarshalling verwendet wird, müssen alle verfügbaren Channel bekannt sein, um dem Client Methodenaufrufe auf dem Remoteobjekt mithilfe der dem Client zur Verfügung stehenden Protokolle zu ermöglichen. Dem Client stehen alle während der Objektregistrierung registrierten Channel zur Verfügung.

Gründe für das Registrieren von Objekten

Das Remotingframework ist für das Aktivieren von Remoteobjekten sowie das Verwalten ihrer Lebensdauer zuständig. Hierfür wird eine Liste aller registrierten Objekte auf dem Objekt-URI verschlüsselt gespeichert. Wenn ein Client eine Methode auf dem Proxyserver aufruft, wird der Methodenaufruf in einer Nachricht zurückgegeben, die dann über den relevanten Channel an die Anwendungsdomäne weitergeleitet wird, die sich im vom Client angegebenen URL befindet. Kommt der Aufruf beim Server an (der Anwendungsdomäne, unter der das Objekt verwaltet wird), verwendet das Framework ObjectUri zum Suchen von ObjRef des Objekts in der Identitätstabelle. Wird ObjRef gefunden, aktiviert das Framework bei Bedarf das Objekt und leitet den Methodenaufruf an das Objekt weiter.

Es gibt folgende zwei verschiedene serveraktivierte Objekttypen:

• Wellknown-Objekte vom Typ SingleCall behalten den Status zwischen Methodenaufrufen nicht bei. Für jeden auf dem Objekt durchgeführten Methodenaufruf wird eine neue Objektinstanz erstellt. Bei Beendigung des Aufrufs wird ein optionales Ergebnis an den Aufrufer zurückgegeben, und das Objekt wird erneut verwendet.

• Singleton-Objekte behalten den Status zwischen Methodenaufrufen bei. Wenn das Objekt registriert wird, instanziiert das Framework eine einzelne Instanz des Objekts. Alle auf diesem Objekt durchgeführten Methodenaufrufe werden an die erstellte Einzelinstanz geleitet. Die Entwickler müssen sicherstellen, dass singleton-Objekte so geschützt sind, dass sie in einer Multithread-Umgebung funktionieren.

Wellknown-Objekte können nur in der AppDomain veröffentlicht/gemarshallt werden, in der sie erstellt wurden.
Werden kontextgebundene Objekte erstellt, wird ein übereinstimmender Kontext gefunden oder erstellt, der die Anforderungen an die Kontexteigenschaften für das Objekt erfüllt. Weitere Einzelheiten erhalten Sie im Abschnitt zum Kontext.

Wird ein Serverobjekt gemarshallt, wird die zum Objekt führende Serverobjekt-Empfängerkette erstellt. Der Stack-Builder ist der letzte Empfänger in der Serverobjektkette und kommuniziert direkt mit dem Serverobjekt. Der Stack-Builder wird von der Remotinginfrastruktur bereitgestellt. Wenn ein kontextgebundenes Objekt gemarshallt wird, wird der Verweis auf den Erstellungskontext des Objekts im Eintrag in der Identitätstabelle gespeichert.

Kommen eingehende Aufrufe an, werden sie auf dem Serverobjekt verteilt. Die Identitätstabelle stellt den URI für die Empfängerkettenzuordnungen der Objekte, Kontexte und Nachrichten bereit.

Einstellungsschema

Enthält Tags, die zum Platzieren von benutzerdefinierten Einstellungen in Konfigurationsdateien von Remotinganwendungen verwendet werden.

Beschreibung:
Gibt die serveraktivierten oder wellknown-Objekte an, die der Dienst bereitstellt. Kein oder mehrere dieser Elemente können angegeben werden.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Mode: serveraktivierter Objekttyp. Für dieses Attribut sind singleton und singlecall gültige Werte.
Type: kompletter Typname (type,assembly) des Objekts.
ObjectUri: gibt den URI des Remoteobjekts an. Dabei handelt es sich um den "Endpunkt", mit dem Remoteobjekte Verbindungen herstellen. Dieses Attribut kann nur im <service>-Tag verwendet werden. Beim Zugriff auf das Objekt über IIS ist die SOAP-Erweiterung erforderlich. Diese Erweiterung beachtet Groß- und Kleinschreibung nicht.
Url: gibt den URL an, der bei der Verbindungsherstellung mit dem Dienst zu verwenden ist. Dieses Attribut kann nur im <client>-Tag verwendet werden.
Optionale Attribute:
displayName: ist dieses Attribut (in einem <client>-Tag) vorhanden, wird es vom Admin-Tool verwendet, um Benutzern das Unterscheiden zwischen den verschiedenen aufgelisteten Objekten zu ermöglichen, wenn mehr als ein wellknown-Objekt im <client>-Abschnitt der Konfigurationsdatei aufgelistet ist.
Beispiel:
Anhand des unten folgenden Beispiels wird veranschaulicht, wie dieses Element beim Definieren eines wellknown-Dienstes zu verwenden ist.

<configuration> 
  <system.runtime.remoting> 
    <application> 
      <service> 
        <wellknown mode="SingleCall" type="Hello.HelloService, Hello"  
objectUri="HelloService.soap" /> 
      </service> 
    </application> 
  </system.runtime.remoting> 
</configuration> 
In dem unten folgenden Beispiel wird die Verwendung dieses Elements im <client>-Tag veranschaulicht. 
<configuration> 
  <system.runtime.remoting> 
    <application> 
      <client> 
        <wellknown type="Hello.HelloService, Hello"  
url="https://localhost:8000/HelloService.soap" /> 
      </client> 
    </application> 
  </system.runtime.remoting> 
</configuration>

Beschreibung der Elemente

<activated>

Übergeordnetes Element:
service, client
Beschreibung:
Gibt die clientaktivierten Objekte an, die die Anwendung veröffentlichen möchte. Kein oder mehr Elemente können unter den Tags <service> oder <client> platziert werden.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Type: kompletter Typname (type,assembly) des Objekts. Dieser Tag kann sowohl in <service>- als auch <client>-Tags verwendet werden.
Optionale Attribute:
Keine
Beispiel:
Anhand des unten folgenden Beispiels wird veranschaulicht, wie dieses Element beim Definieren eines clientaktivierten Dienstes zu verwenden ist.

<configuration> 
  <system.runtime.remoting> 
    <application> 
      <service> 
        <activated type="Hello.AddService, Hello"/> 
      </service> 
    </application> 
  </system.runtime.remoting> 
</configuration>

In dem unten folgenden Beispiel wird die Verwendung dieses Elements im <client>-Tag veranschaulicht.

<configuration> 
  <system.runtime.remoting> 
    <application> 
      <client url="http://localhost:8000> 
        <activated type="Hello.AddService, Hello"/> 
      </client> 
    </application> 
  </system.runtime.remoting> 
</configuration>

<channels>

Übergeordnetes Element:
system.runtime.remoting, application
Beschreibung:
Wenn dieses Element in den <application>-Tag platziert wird, wird es zum Konfigurieren bereits vorhandener, unter <system.runtime.remoting> definierter Channel verwendet. Platzieren Sie einen <channels>-Tag direkt unter <system.runtime.remoting>, um neue Channel zu definieren. In der machine.config-Datei sind Standardchannel definiert. Solange Sie keine neuen Channel registrieren, müssen Sie auf dieser Ebene keine Channel definieren.
Untergeordnete Elemente:
channel
Erforderliche Attribute:
Keine
Optionale Attribute:
Keine
Beispiel:

<configuration> 
  <system.runtime.remoting> 
    <application> 
      <channels> 
      </channels> 
    </application> 
    <channels> 
    </channels> 
  </system.runtime.remoting> 
</configuration>

<channel>

Übergeordnetes Element:
Alle im obigen <channels>-Abschnitt beschriebenen Tags.
Beschreibung:
Kein oder mehrere <channel>-Tags können zum Konfigurieren einzelner Channel im Anwendungschannelknoten platziert werden. Bedenken Sie bitte, dass die auf einem Channel platzierten Attribute vom Channel und nicht durch Remoting festgelegt werden. So kann z. B. ein komplett neuer Channel erstellt werden, der keine der in dieser Unterlage beschriebenen Attribute erfordert.
Untergeordnete Elemente:
ClientProviders und ServerProviders, wenn der übergeordnete <channels>-Tag unter <system.runtime.remoting> platziert wurde. Ist der übergeordnete Tag unter dem <application>-Tag platziert, kann nur auf bereits deklarierte Channel verwiesen werden.
Erforderliche Attribute:
Beim Deklarieren von Channelvorlagen sind folgende Attribute erforderlich. Der <channels>-Tag wird unter <system.runtime.remoting> platziert. Ein Channel kann auch im application-Abschnitt deklariert werden, wobei alle Attribute für den Channel als Teil dieser Deklaration bereitgestellt werden müssen.
Id: gibt einen Namen für den Channel an, der beim Verweisen auf ihn verwendet werden kann. Wird der Channel zum Beispiel "TCP" genannt, kann unter dem Anwendungschanneltag auf ihn verwiesen werden. Verdoppelte IDs sind nicht zulässig, und der Parser löst keine Ausnahme aus, wenn Duplikate gefunden werden. Die zuletzt gefundene ID ist mit dem Channel verbunden.
Type: kompletter Name des Channels, der geladen wird.
Ref: Channelvorlage, auf die verwiesen wird. Der für dieses Attribut angegebene Wert wird zum Suchen des Channels verwendet, auf den mit einer übereinstimmenden Channel-ID verwiesen wird, die auf Rechnerebene angegeben ist. Auf Channel wird in der Regel verwiesen, damit sie Channelattributen Werte bereitstellen. Wenn z. B. der in der machine.config-Datei definierte TCP-Channel an Port 8000 verwendet werden muss, wird im application-Abschnitt einfach auf den Channel verwiesen und eine Anschlussnummer für ihn bereitgestellt. Wichtig: Beachten Sie bitte, dass vom template-Abschnitt auf keine bereits vorhandene Channelvorlage verwiesen werden kann.
Optionale Attribute:
Beim Deklarieren von Channelvorlagen können folgende optionale Attribute verwendet werden.
Name: gibt den Namen des Channels an. Manchmal ist es erforderlich, denselben Channel mehrmals zu konfigurieren. Zum Beispiel, wenn der TCP-Channel zum Überwachen der Ports 8000 und 9000 verwendet werden muss. Beim Versuch, mit verschiedenen Channelnummern mehrmals auf denselben Channel zu verweisen, wird eine Ausnahme ausgelöst, da Sie denselben Channel nur einmal registrieren dürfen. Stattdessen müssen Sie zu allen Channelverweisen das "name"-Attribut hinzufügen und einen jeweils anderen Namen angeben (vgl. unten folgendes Beispiel).
Priority: gibt eine Einstellung für den Channel an, die beim Einstellen der Art der Verbindungsherstellung mit dem Dienst festgelegt wird. Versuchen Sie nun, eine Verbindung mit einem Remoteobjekt herzustellen, verwendet Remoting die im URL angegebenen Informationen, um den für die Anfragebehandlung entsprechenden Channel zu suchen. Es wird der erste Channel verwendet, der angibt, dass er die Anfrage behandeln kann. Dieses Attribut ermöglicht Ihnen, im channel-Abschnitt die bevorzugte Einstellung vorzunehmen. Alle mit dem SDK gelieferten Standardchannel weisen standardmäßig Priorität 1 auf. Höhere Zahlen bedeuten höhere Priorität (negative Zahlen sind zulässig). Bei der Verbindungsherstellung mit einem Objekt auf Clientseite haben Channel mit höherer Priorität Vorrang. Wenn sie als Serverchannel agieren, werden ihre Channeldaten zuerst durchsucht.
DisplayName: wird vom Admin-Tool verwendet, um Benutzern Channelinformationen anzuzeigen. Dieses Attribut wird nur im template-Abschnitt verwendet.
DelayLoadAsClientChannel: gibt an, ob dieser Channel geladen werden soll, wenn der Client keinen Channel für die Anwendung registriert hat. Dabei handelt es sich um einen booleschen Wert, der nur das Verhalten des Client betrifft. Der Wert TRUE gibt an, dass .NET Remoting diesen Channel zur Laufzeit auf Unterstützung einer Clientverbindung mithilfe des bestimmten Protokollschemas testet, das im remoten Aktivierungs-URL angegeben ist. Ist kein Wert vorhanden, lautet der Standardwert FALSE.
CustomChannelProperty: gibt ein Name/Wert-Paar für Channelattribute an. Channeleigenschaften werden nicht von Remoting angegeben, da jede Channelimplementierung eigene Anforderungen hat. Der Begriff customChannelProperty wird hier nur zu Erläuterungszwecken verwendet.

<channel id="CustomChannel" type="Namespace.CustomChannel, CustomChannels" myProperty="myValue"/>

Die folgenden Attribute können für Anwendungschannel verwendet werden.
Konfigurieren des HTTP-Channels:
Der HTTP-Channel verfügt über folgende weitere optionale Attribute.
Port: jede gültige Anschlussnummer. Der Port, den der Channel überwachen soll.
ClientConnectionLimit: gibt die Anzahl der Verbindungen an, die einem bestimmten Server gleichzeitig geöffnet werden können. Der Standardwert ist 2. Dieser Wert stimmt exakt mit der Verbindungsbegrenzung auf dem ServicePoint in den net-Klassen überein.
ProxyName: ermöglicht das Konfigurieren des Channels für die Verwendung mit einem Proxyserver. Der Name des Proxyservers steht hier.
ProxyPort: ermöglicht das Konfigurieren des Channels für die Verwendung mit einem Proxyserver. Die Anschlussnummer steht hier.
Listen: Geben Sie hier true ein, wenn während der Aktivierung IChannelReceiverHook.WantsToListen auf dem Channel aufgerufen werden soll. Wenn es keine Überwachungschannel gibt, dann registriert Remoting einen eigenen. Wenn Sie eine Anschlussnummer festlegen, wird dieses Attribut auf FALSE festgelegt.
SuppressChannelData: legen Sie diesen Wert auf FALSE fest, wenn der Channel ChannelData für ObjRef nicht berücksichtigt.
UseIpAddress: ermöglicht Ihnen, festzulegen, ob die IP-Adresse bzw. der Rechnername im URL verwendet werden soll. Dieses Attribut wird nur serverseitig verwendet. Der Standardwert ist TRUE.
BindTo: gibt eine IP-Adresse der NIC an, mit der eine Bindung erstellt werden soll, wenn mehrere NICs auf einem Rechner installiert sind. Dieses Attribut kann nur serverseitig verwendet werden.
MachineName: setzt den Rechnernamen außer Kraft, der in den Channeldaten verwendet wird. Dieses Attribut setzt useIpAddress außer Kraft.
Konfigurieren des TCP-Channels:
Der TCP-Channel verfügt über folgende weitere optionale Attribute.
Port: jede gültige Anschlussnummer. Der Port, den der Channel überwachen soll.
SuppressChannelData: legen Sie diesen Wert auf FALSE fest, wenn der Channel ChannelData für ObjRef nicht berücksichtigt.
UseIpAddress: ermöglicht Ihnen, festzulegen, ob die IP-Adresse bzw. der Rechnername im URL verwendet werden soll. Dieses Attribut wird nur serverseitig verwendet. Der Standardwert ist TRUE.
RejectRemoteRequests: verweigert Verbindungen von anderen Rechnern. Wird dieses Attribut auf TRUE gesetzt, werden nur prozessübergreifende Verbindungen zugelassen.
BindTo: gibt eine IP-Adresse der NIC an, mit der eine Bindung erstellt werden soll, wenn mehrere NICs auf einem Rechner installiert sind. Dieses Attribut kann nur serverseitig verwendet werden.
Beispiel:
Das unten folgende Beispiel veranschaulicht, wie ein Channel im application-Abschnitt deklariert wird.

<configuration> 
  <system.runtime.remoting> 
    <application name="RemotingHello"> 
      <lifetime leaseTime="20ms" sponsorshipTimeOut="20ms"  
renewOnCallTime="20ms" />   
      <service> 
        <wellknown mode="SingleCall" type="Hello.HelloService, MyHello,  
Version=1.0.0.0, PublicKeyToken=bef6d8db915d3112,Culture=Neutral"  
objectUri="HelloService.soap" /> 
        <activated type="Hello.AddService, MyHello"/> 
      </service> 
      <channels> 
        <channel port="8000"  
type="System.Runtime.Remoting.Channels.Http.HttpChannel,  
System.Runtime.Remoting"> 
         </channel>   
      </channels> 
    </application> 
  </system.runtime.remoting> 
</configuration>

Das folgende Beispiel veranschaulicht, wie ein Channel im template-Abschnitt deklariert und auf ihn von dem application-Abschnitt aus verwiesen wird.

<configuration> 
  <system.runtime.remoting> 
    <application name="RemotingHello"> 
      <lifetime leaseTime="20ms" sponsorshipTimeOut="20ms"  
renewOnCallTime="20ms" />   
      <service> 
        <wellknown mode="SingleCall" type="Hello.HelloService, MyHello,  
Version=1.0.0.0, PublicKeyToken=bef6d8db915d3112,Culture=Neutral"  
objectUri="HelloService.soap" /> 
        <activated type="Hello.AddService, MyHello"/> 
      </service> 
      <channels> 
        <channel ref="http1" name="foo1" port="8000" /> 
      </channels> 
    </application> 
    <channels> 
      <channel id="http1"  
type="System.Runtime.Remoting.Channels.Http.HttpChannel,  
System.Runtime.Remoting"> 
       </channel>  
    </channels> 
  </system.runtime.remoting> 
</configuration>

<channelSinkProviders>

Übergeordnetes Element:
system.runtime.remoting
Beschreibung:
Alle channelempfängerverbundenen Tags sind unter diesen Tag zu platzieren. Nur eines dieser Elemente darf verwendet werden.
Untergeordnete Elemente:
clientProviders, serverProviders
Erforderliche Attribute:
Keine
Optionale Attribute:
Keine

<serverProviders>

Übergeordnetes Element:
system.runtime.remoting, channel
Beschreibung:
Wenn dieses Element in den <channel>-Tag platziert wird, wird es zum Konfigurieren bereits vorhandener, unter <system.runtime.remoting> definierter Empfängeranbieter verwendet. Dieses Element kann auch unter den <channel>-Tag platziert werden (die Vorlage oder der in der Anwendung). Platzieren Sie einen <serverProviders>-Tag direkt unter <system.runtime.remoting>, um neue Empfängeranbieter zu definieren. In der machine.config-Datei werden auch standardmäßige Empfängeranbieter definiert. Solange Sie keine neuen Empfängeranbieter registrieren, müssen Sie auf dieser Ebene keine Anbieter definieren. Nur eines dieser Elemente darf verwendet werden.
Untergeordnete Elemente:
formatter, provider
Erforderliche Attribute:
Keine
Optionale Attribute:
Keine
Hinweise:
Wichtig: Bedenken Sie bitte, dass alle Standardanbieter oder -formatierungsprogramme für einen Channel außer Kraft gesetzt werden, wenn dieses Element auf Formatierungsprogramme oder Anbieter in einem <channel>-Element verweist oder sie deklariert. In diesem Fall müssen Sie alle Anbieter und das mit dem Channel zu verwendende Formatierungsprogramm deklarieren. Die Reihenfolge, in der Anbieter und Formatierungsprogramme aufgelistet werden, entspricht der Reihenfolge, in der die Empfängerkette assembliert wird. Wird z. B. ein Anbieter vor einem Formatierungsprogramm clientseitig hinzugefügt, wird eine Ausnahme ausgelöst, wenn der Anbieter die für ein Formatierungsprogramm erforderlichen Schnittstellen nicht implementiert.

<clientProviders>

Übergeordnetes Element:
system.runtime.remoting, channel
Beschreibung:
Wenn dieses Element in den <channel>-Tag platziert wird, wird es zum Konfigurieren bereits vorhandener, unter <system.runtime.remoting> definierter Empfängeranbieter verwendet. Platzieren Sie einen <clientProviders>-Tag direkt unter <system.runtime.remoting>, um neue Empfängeranbieter zu definieren. In der machine.config-Datei sind standardmäßige Empfängeranbieter definiert. Solange Sie keine neuen Empfängeranbieter registrieren, müssen Sie auf dieser Ebene keine Anbieter definieren. Nur eines dieser Elemente darf verwendet werden.
Untergeordnete Elemente:
formatter, provider
Erforderliche Attribute:
Keine
Optionale Attribute:
Keine
Hinweise:
Wichtig: Bedenken Sie bitte, dass alle Standardanbieter oder -formatierungsprogramme für einen Channel außer Kraft gesetzt werden, wenn dieses Element auf Formatierungsprogramme oder Anbieter in einem <channel>-Element verweist oder sie deklariert. In diesem Fall müssen Sie alle Anbieter und das mit dem Channel zu verwendende Formatierungsprogramm deklarieren. Die Reihenfolge, in der Anbieter und Formatierungsprogramme aufgelistet werden, entspricht der Reihenfolge, in der die Empfängerkette assembliert wird. Wird z. B. ein Anbieter vor einem Formatierungsprogramm clientseitig hinzugefügt, wird eine Ausnahme ausgelöst, wenn der Anbieter die für ein Formatierungsprogramm erforderlichen Schnittstellen nicht implementiert.

<provider>

Übergeordnetes Element:
clientProviders, serverProviders
Beschreibung:
Der angegebene Channelempfängeranbieter für einen Channelempfänger, der in die Channelempfängerkette eingefügt werden soll. Dieser Tag kann unter <serverProvider> oder <clientProvider> platziert werden. Sie können keines oder mehrere dieser Elemente verwenden.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Id: die ID gibt den Namen an, den Sie im application-Abschnitt zum Verweisen auf den Anbieter verwendet haben.
Type: der Typ gibt die Klasse/Assembly an, die für diesen Anbieter instanziiert werden müssen.
Ref: gibt die ID der Anbietervorlage an, die der Channel zu verwenden versucht. Dieses Attribut kann nicht in der Anbietervorlage selbst verwendet werden.
Optionale Attribute:
Properties: gibt weitere Eigenschaften für den Anbieter an. Die anzugebenden Eigenschaften werden von den Anbietern selbst festgelegt. Der Name des XML-Tags ist nicht wichtig, da alle Daten unter dem Knoten als DOM-Struktur übergeben werden.
Alle XML-Attribute auf dem Knoten und alle XML-Abschnitte unterhalb des Anbieterknotens werden "in Pakete gepackt" und zum Anbieterkonstruktor weitergeleitet, wenn Remoting die in einer Konfigurationsdatei angegebenen Anbieter erstellt. Alle in einer Konfigurationsdatei angegebenen Anbieter müssen einen Konstruktor haben, der IDictionary und ICollection als Parameter nimmt. Das Wörterbuch enthält die auf dem Anbieterknoten angegebenen XML-Attribute. Die Sammlung ist immer eine Sammlung von SinkProviderData, einer DOM-Struktur der Unterknoten.
Beispiel:

<configuration> 
<system.runtime.remoting> 
<application name="MyFoo"> 
  <service> 
    <wellknown type="Foo, common" objectUri="Foo.soap" mode="Singleton"  
/> 
  </service> 
  <channels> 
    <channel ref="http server" name="MyHttpChannel" port="9000"> 
      <serverProviders>         
        <provider ref="ip filter" mode="accept"> 
          <filter mask="255.255.255.255" ip="127.0.0.1" />           
        </provider> 
        <formatter ref="soap" /> 
      </serverProviders> 
    </channel> 
  </channels> 
</application> 
<channelSinkProviders> 
  <serverProviders> 
    <provider id="ip filter"  
type="IPFilter.IPFilterChannelSinkProvider, IPFilterSink" /> 
  </serverProviders> 
</channelSinkProviders></system.runtime.remoting> 
</configuration>

<formatter>

Übergeordnetes Element:
clientProviders, serverProviders
Beschreibung:
Zum Angeben eines Formatierungsprogramms, das in die Channelempfängerkette eingefügt wird. Dieser Tag kann unter <serverProvider> oder <clientProvider> platziert werden. Sie können keines oder mehrere dieser Elemente verwenden.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Id: die ID gibt den Namen an, den Sie im application-Abschnitt zum Verweisen auf das Formatierungsprogramm verwenden.
Type: der Typ gibt die Klasse/Assembly an, die für dieses Formatierungsprogramm instanziiert werden müssen.
Ref: gibt die ID der Formatierungsprogrammvorlage an, die der Channel zu verwenden versucht. Dieses Attribut kann nicht in der Formatierungsprogrammvorlage selbst verwendet werden.
Optionale Attribute:
IncludeVersions: gibt an, dass das Formatierungsprogramm beim Serialisieren von Typen die komplette Version einschließen soll.
StrictBinding: gibt an, dass das Formatierungsprogramm keine teilweisen Bindungen beim Deserialisieren von Objekten verwenden soll. Ist es auf FALSE eingestellt, werden Typen mithilfe ihrer starken Namen geladen. Schlägt dies fehl, wird der Typ mithilfe von teilweisen Bindungen geladen. Schlägt dies fehl, wird eine Ausnahme ausgelöst. Dieses Attribut steht nur im RTM SDK zur Verfügung.
Properties: gibt weitere Eigenschaften für das Formatierungsprogramm an. Die Eigenschaften, die angegeben werden können, werden von den Formatierungsprogrammen selbst festgelegt. Der Name des XML-Tags ist nicht wichtig, da alle Daten unter dem Knoten als DOM-Struktur übergeben werden.
Alle XML-Attribute auf dem Knoten und alle XML-Abschnitte unterhalb des Formatierungsprogrammknotens werden "gepackt" und zum Formatierungsprogrammkonstruktor weitergeleitet, wenn Remoting die in einer Konfigurationsdatei angegebenen Formatierungsprogramme erstellt. Alle in einer Konfigurationsdatei angegebenen Formatierungsprogramme müssen einen Konstruktor haben, der IDictionary und ICollection als Parameter nimmt. Das Wörterbuch enthält die auf dem Formatierungsprogrammknoten angegebenen XML-Attribute. Die Sammlung ist immer eine Sammlung von SinkProviderData, einer DOM-Struktur der Unterknoten.

<soapInterop>

Übergeordnetes Element:
system.runtime.remoting
Beschreibung:
Gibt mit SOAP verwendete Typzuordnungen an.
Untergeordnete Elemente:
preLoad, interopXmlElement, interopXmlType
Erforderliche Attribute:
Keine
Optionale Attribute:
Keine

<preLoad>

Übergeordnetes Element:
soapInterop
Beschreibung:
Lädt Zuordnungen für alle Klassen, die SoapAttribute erweitern. Auch wenn diese Typen für die Serialisierung automatisch ausgewählt werden, erfordert .NET Remoting diese Konfigurationselemente (oder das Aufrufen des programmatischen Äquivalents) zum erfolgreichen Deserialisieren.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Keine
Optionale Attribute:
Type: gibt den für die Deserialisierung zu ladenden Typ an.
Assembly: lädt alle Typen, die in der Assembly angegeben sind.
Beispiel:
Im folgenden Beispiel werden das Element ElementName und der XML-Namespace Example:mynamespace mit dem .NET-Typ TypeName durch die Assembly AssemblyName implementiert. Dasselbe gilt für den XML-Typ und -Namespace.

<configuration> 
   <system.runtime.remoting> 
      <application name="soapInterop"> 
         <soapInterop> 
            <interopXmlElement  
               xml="ElementName,Example:mynamespace"                 
clr="TypeName,AssemblyName" 
            /> 
            <interopXmlType   
               xml="XmlTypeName,Example:TypeNamespace"  
               clr="TypeName,AssemblyName" 
            /> 
            <preLoad 
               type="TypeName" 
               assembly="AssemblyName" 
         </soapInterop> 
      </application> 
   </system.runtime.remoting> 
</configuration>

<interopXmlElement>

Übergeordnetes Element:
soapInterop
Beschreibung:
Erstellt eine bidirektionale Zuordnung zwischen einem allgemeinen Sprachlaufzeittyp und einem XML-Element und XML-Namespace. Kann einmal oder mehrmals auftreten.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Clr: gibt den kompletten Typ- sowie Assemblynamen des Typs an, für den Sie eine Zuordnung mit dem XML-Element und XML-Namespace erstellen möchten.
Xml: gibt das XML-Element sowie den XML-Namespace an, für den Sie eine Zuordnung mit einem Typen und einer Assembly erstellen möchten.
Optionale Attribute:
Keine
Beispiel:
Im folgenden Beispiel werden das Element ElementName und der XML-Namespace Example:mynamespace mit dem .NET-Typ TypeName durch die Assembly AssemblyName implementiert. Dasselbe gilt für den XML-Typ und -Namespace.

<configuration> 
   <system.runtime.remoting> 
      <application name="soapInterop"> 
         <soapInterop> 
            <interopXmlElement  
               xml="ElementName,Example:mynamespace"                 
clr="TypeName,AssemblyName" 
            /> 
            <interopXmlType   
               xml="XmlTypeName,Example:TypeNamespace"  
               clr="TypeName,AssemblyName" 
            /> 
         </soapInterop> 
      </application> 
   </system.runtime.remoting> 
</configuration>

<interopXmlType>

Übergeordnetes Element:
soapInterop
Beschreibung:
Erstellt eine bidirektionale Zuordnung zwischen einem allgemeinen Sprachlaufzeittyp und einem XML-Element und XML-Namespace, wenn der Elementname nicht geändert werden kann. Nur eines dieser Elemente darf verwendet werden.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
Clr: gibt den kompletten Typ- sowie Assemblynamen des Typs an, für den Sie eine Zuordnung mit dem XML-Typen und XML-Namespace erstellen möchten.
Xml: gibt den XML-Typnamen sowie den XML-Typnamespace an, für den Sie eine Zuordnung mit einem Typen und einer Assembly erstellen möchten.
Optionale Attribute:
Keine
Beispiel:
Im folgenden Beispiel werden das Element ElementName und der XML-Namespace Example:mynamespace mit dem .NET-Typ TypeName durch die Assembly AssemblyName implementiert. Dasselbe gilt für den XML-Typ und -Namespace.

<configuration> 
   <system.runtime.remoting> 
      <application name="soapInterop"> 
         <soapInterop> 
            <interopXmlElement  
               xml="ElementName,Example:mynamespace"                 
clr="TypeName,AssemblyName" 
            /> 
            <interopXmlType   
               xml="XmlTypeName,Example:TypeNamespace"  
               clr="TypeName,AssemblyName" 
            /> 
         </soapInterop> 
      </application> 
   </system.runtime.remoting> 
</configuration>

<debug>

Übergeordnetes Element:
system.runtime.remoting
Beschreibung:
Gibt an, ob bei Anwendungsstart Typen in die Konfigurationsdatei geladen werden sollen. Dieses Element kann nicht angegeben werden, wenn der Name der Konfigurationsdatei web.config lautet und der Remotetyp in IIS verwaltet wird.
Untergeordnete Elemente:
Keine
Erforderliche Attribute:
loadTypes: gibt an, ob bei Anwendungsstart alle in der Konfigurationsdatei angegebenen Typen geladen werden sollen. Hierdurch kann vermieden werden, dass sich einfache Tippfehler zu einem ärgerlichen Debuggingaufwand auswachsen.
Optionale Attribute:
Keine
Beispiel:
Die folgende Beispielkonfigurationsdatei teilt dem .NET Remoting-System mit, dass bei Anwendungsstart versucht werden soll, die in dieser Datei angegebenen Typen zu laden (in diesem Fall die Typen ServiceClass und TcpChannel).

<configuration> 
   <system.runtime.remoting> 
      <application> 
         <client> 
            <wellknown  
               type="ServiceClass, IService" 
               url="tcp://computername:8080/TcpService" 
            /> 
         </client> 
         <channels> 
            <channel ref="tcp"/> 
         </channels> 
      </application> 
      <debug loadTypes="true" /> 
   </system.runtime.remoting> 
</configuration>

Namenskonventionen für Konfigurationsdateien
Konfigurationsdateien werden auch zum Speichern solcher Einstellungen wie Bindungs- und Sicherheitsrichtlinien verwendet. Alle EXE- und COM-Hosts generieren automatisch eine Konfigurationsdatei für die von ihnen erstellten Anwendungsdomänen. Der Name dieser Konfigurationsdatei ist der komplette Modulname einschließlich der Erweiterung. So lautet für foo.exe der Name der Konfigurationsdatei foo.exe.config. Auch wenn .NET Remoting nicht vorschreibt, wie der Name der Konfigurationsdatei lauten muss, wird Entwicklern nahegelegt, die oben dargelegte Namenskonvention zu verwenden, um sicherzustellen, dass die angegebenen Sicherheits- und Bindungsrichtlinien bei Anwendungsausführung ausgewählt werden.

Der Name der Konfigurationsdatei der Anwendung kann von AppDomain wie folgt abgerufen werden:

String configfilename =  
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

In manchen Situationen möchten Sie möglicherweise mehrere Konfigurationsdateien zum Konfigurieren einer Remoteanwendung verwenden. Entwickler müssen daher sicherstellen, dass sie diese zusätzlichen Remotingkonfigurationsdateien nicht zum Speichern von Sicherheits- oder Bindungsrichtlinien verwenden, da diese bei Anwendungsausführung nicht gelesen werden. Der configure-Aufruf auf RemotingConfiguration liest nur relevante Abschnitte in der Konfigurationsdatei, die auf Remoting angewendet werden. Die restlichen Informationen werden übergangen.