Marshalling di interoperabilità

Il marshalling di interoperabilità determina il modo in cui i dati vengono passati negli argomenti del metodo e restituiscono valori tra memoria gestita e non gestita durante le chiamate. Il marshalling di interoperabilità è un'attività di runtime eseguita dal servizio di marshalling di Common Language Runtime.

La maggior parte dei tipi di dati ha rappresentazioni comuni sia nella memoria gestita che in quella non gestita. Il marshaller di interoperabilità gestisce automaticamente questi tipi. Altri tipi possono essere ambigui o non rappresentati affatto in memoria gestita.

Un tipo ambiguo può avere sia più rappresentazioni non gestite che corrispondono a un singolo tipo gestito, sia informazioni sul tipo mancanti, come la dimensione di un array. Per i tipi ambigui, il marshaller fornisce una rappresentazione predefinita e rappresentazioni alternative in cui esistono più rappresentazioni. È possibile fornire istruzioni esplicite al gestore su come gestire un tipo ambiguo.

Modelli di interoperabilità Platform Invoke e COM

Common Language Runtime offre due meccanismi per l'interoperabilità con codice non gestito:

• Platform invoke, che consente al codice gestito di chiamare le funzioni esportate da una libreria non gestita.
• Interoperabilità COM, che consente al codice gestito di interagire con oggetti COM (Component Object Model) tramite interfacce.

Sia il platform invoke che l'interoperabilità COM usano il marshalling dell'interoperabilità per spostare in modo accurato gli argomenti del metodo tra il chiamante e il chiamato, e viceversa, se necessario. Come illustrato nella figura seguente, una chiamata al metodo platform invoke passa da codice gestito a codice non gestito e mai in altro modo, tranne quando sono coinvolte le funzioni di callback . Anche se le chiamate platform invoke possono fluire solo da codice gestito a codice non gestito, i dati possono essere trasmessi in entrambe le direzioni come parametri di input o output. Le chiamate al metodo di interoperabilità COM possono essere propagate in entrambe le direzioni.

Al livello più basso, entrambi i meccanismi usano lo stesso servizio di marshalling per l'interoperabilità; tuttavia, alcuni tipi di dati sono supportati esclusivamente dall'interoperabilità COM o da platform invoke. Per informazioni dettagliate, vedere Comportamento di marshalling predefinito.

Marshalling e appartamenti COM

Il marshaller di interoperabilità esegue il marshalling dei dati tra l'heap di Common Language Runtime e l'heap non gestito. Il marshalling si verifica ogni volta che il chiamante e il chiamato non possono operare sulla stessa istanza di dati. Il marshaller di interoperabilità consente al chiamante e al chiamato di operare sugli stessi dati pur avendo la propria copia dei dati.

COM dispone anche di un marshaller che effettua il marshalling dei dati tra appartamenti COM o processi COM diversi. Quando si effettuano chiamate tra codice gestito e non gestito all'interno dello stesso contesto COM, il marshaller di interoperabilità è l'unico marshaller coinvolto. Quando si effettua una chiamata tra codice gestito e codice non gestito in un diverso apartment COM o in un processo differente, sono coinvolti sia il marshaller di interop che il marshaller COM.

Client COM e server gestiti

Un server gestito che è stato esportato con una libreria dei tipi registrata dal Regasm.exe (Strumento di registrazione assembly) possiede una ThreadingModel voce del Registro di Sistema impostata su Both. Questo valore indica che il server può essere attivato in un ambiente a thread singolo (STA) o in un ambiente a più thread (MTA). L'oggetto server viene creato nello stesso apartment del chiamante, come illustrato nella tabella seguente:

Client COM	Server .NET	Requisiti di marshalling
STA	Both diventa STA.	Organizzazione all'interno dello stesso appartamento.
MTA	Both diventa MTA.	Organizzazione all'interno dello stesso appartamento.

Poiché il client e il server si trovano nello stesso appartamento, il servizio di interoperabilità per il marshalling gestisce automaticamente tutto il marshalling dei dati. La figura seguente illustra il servizio di marshalling per l'interoperabilità che opera tra heap gestiti e non gestiti all'interno dello stesso appartamento in stile COM.

Se si prevede di esportare un server gestito, tenere presente che il client COM determina l'apartment del server. Un server gestito chiamato da un client COM inizializzato in un MTA deve garantire la thread safety.

Client gestiti e server COM

L'impostazione predefinita per gli appartamenti client gestiti è MTA; Tuttavia, il tipo di applicazione del client .NET può modificare l'impostazione predefinita. Ad esempio, un'impostazione dell'apartment client di Visual Basic è STA. È possibile usare System.STAThreadAttribute, System.MTAThreadAttribute o Thread.ApartmentState proprietà, oppure la proprietà Page.AspCompatMode per esaminare e modificare l'impostazione dell'ambiente di un client gestito.

L'autore del componente imposta l'affinità thread di un server COM. La tabella seguente illustra le combinazioni di impostazioni apartment per i client .NET e i server COM. Mostra anche i requisiti di marshalling che risultano dalle combinazioni.

Client .NET	Server COM	Requisiti di marshalling
MTA (impostazione predefinita)	MTA STA	Marshalling di interoperabilità. Interoperabilità e marshalling COM.
STA	MTA STA	Interoperabilità e marshalling COM. Marshalling di interoperabilità.

Quando un client gestito e un server non gestito si trovano nello stesso apartment, il servizio di interop marshalling gestisce tutto il marshalling dei dati. Tuttavia, quando il client e il server vengono inizializzati in appartamenti diversi, è necessario anche il marshalling COM. La figura seguente illustra gli elementi di una chiamata tra appartamenti.

Per il marshalling tra appartamenti, è possibile eseguire le operazioni seguenti:

• Accettare il sovraccarico del marshalling tra gli appartamenti, che è evidente solo quando ci sono molte chiamate attraverso il confine. È necessario registrare la libreria dei tipi del componente COM affinché le chiamate possano superare correttamente il confine di appartamento.

• Modificare il thread principale impostando il thread client su STA o MTA. Ad esempio, se il client C# chiama molti componenti COM STA, è possibile evitare il marshalling tra appartamenti impostando il thread principale su STA.

  Annotazioni

  Dopo che il thread di un client C# è impostato su STA, le chiamate ai componenti COM MTA richiederanno il marshalling tra apartment.

Per istruzioni su come selezionare esplicitamente un modello di appartamento, vedere Threading gestito e non gestito.

Gestione delle chiamate remote

Come nel marshalling attraverso apartment, il marshalling COM è coinvolto in ogni chiamata tra codice gestito e codice non gestito quando gli oggetti risiedono in processi separati. Per esempio:

• Un client COM che richiama un server gestito in un host remoto usa DCOM (Distributed COM).
• Un client gestito che richiama un server COM in un host remoto usa DCOM.

La figura seguente illustra come il marshalling di interoperabilità e il marshalling COM forniscono canali di comunicazione tra i limiti dei processi e degli host:

Mantenimento dell'identità

Common Language Runtime mantiene l'identità dei riferimenti gestiti e non gestiti. La figura seguente mostra il flusso di riferimenti diretti non gestiti (riga superiore) e riferimenti gestiti diretti (riga inferiore) tra i limiti del processo e dell'host.

In questa illustrazione:

• Un client non gestito ottiene un riferimento a un oggetto COM da un oggetto gestito che ottiene questo riferimento da un host remoto. Il meccanismo di remotizzazione è DCOM.

• Un client gestito ottiene un riferimento a un oggetto gestito da un oggetto COM che ottiene questo riferimento da un host remoto. Il meccanismo di remotizzazione è DCOM.

  Annotazioni

  La libreria dei tipi esportata del server gestito deve essere registrata.

Il numero di confini di processo tra il chiamante e il chiamato è irrilevante; lo stesso riferimento diretto avviene per le chiamate interne ed esterne al processo.

Comunicazione remota gestita

Il runtime fornisce anche la comunicazione remota gestita, che è possibile usare per stabilire un canale di comunicazione tra gli oggetti gestiti attraverso i limiti del processo e dell'host. La comunicazione remota gestita può contenere un firewall tra i componenti di comunicazione, come illustrato nella figura seguente:

Chiamate remote attraverso firewall utilizzando SOAP o la classe TcpChannel

Alcune chiamate non gestite possono essere incanalate tramite SOAP, ad esempio le chiamate tra componenti gestiti e COM.

Argomenti correlati

Titolo	Descrizione
Comportamento di marshalling predefinito	Descrive le regole che il servizio di marshalling di interoperabilità usa per gestire i dati.
Marshalling dei dati con Platform Invoke	Viene descritto come dichiarare i parametri del metodo e passare argomenti alle funzioni esportate da librerie non gestite.
Marshalizzazione dei dati con l'interoperabilità COM	Viene descritto come personalizzare i wrapper COM per modificare il comportamento di marshalling.
Procedura: Eseguire la migrazione di Managed-Code DCOM a WCF	Viene descritto come eseguire la migrazione da DCOM a WCF.
Procedura: Eseguire il mapping di HRESULT e delle eccezioni	Descrive come eseguire il mapping di eccezioni personalizzate a HRESULTs e fornisce il mapping completo da ogni HRESULT alla relativa classe di eccezione paragonabile in .NET Framework.
Interoperabilità con tipi generici	Descrive le azioni supportate quando si usano tipi generici per l'interoperabilità COM.
Interoperabilità con codice non gestito	Descrive i servizi di interoperabilità forniti da Common Language Runtime.
Interoperabilità COM avanzata	Fornisce collegamenti ad altre informazioni sull'incorporazione di componenti COM nell'applicazione .NET Framework.
Considerazioni sulla progettazione per l'interoperabilità	Fornisce suggerimenti per la scrittura di componenti COM integrati.

Riferimenti

System.Runtime.InteropServices