Comunicazione interprocesso (IPC)

Questo argomento illustra vari modi per eseguire la comunicazione interprocesso (IPC) tra applicazioni piattaforma UWP (Universal Windows Platform) e applicazioni Win32.

Servizi app

I servizi app consentono alle applicazioni di esporre i servizi che accettano e restituiscono contenitori di proprietà di primitive (ValueSet) in background. Gli oggetti rich possono essere passati se vengono serializzati.

I servizi app possono essere eseguiti come attività in background o in fase di elaborazione all'interno dell'applicazione in primo piano.

I servizi app sono usati ideali per la condivisione di piccole quantità di dati, in cui non è necessaria la latenza in tempo quasi reale.

COM

COM è un sistema distribuito orientato agli oggetti per la creazione di componenti software binari in grado di interagire e comunicare. Gli sviluppatori usano COM per creare componenti software riutilizzabili e livelli di automazione per un'applicazione. I componenti COM possono essere in fase di elaborazione o fuori processo e possono comunicare tramite un modello client e server. I server COM out-of-process sono tradizionalmente osati come mezzo per la comunicazione tra oggetti.

Le applicazioni in pacchetto con la funzionalità runFullTrust possono registrare server COM out-of-process per IPC tramite il manifesto del pacchetto. Questa operazione è nota come COM in pacchetto.

File System

BroadFileSystemAccess

Le applicazioni in pacchetto possono eseguire IPC usando il file system generale dichiarando la funzionalità con restrizioni broadFileSystemAccess. Questa funzionalità concede accesso al file system generale alle API Win32 Windows.Storage e xxxFromApp.

Per impostazione predefinita, IPC tramite il file system per le applicazioni in pacchetto è limitato agli altri meccanismi descritti in questa sezione.

PublisherCacheFolder

PublisherCacheFolder consente alle applicazioni in pacchetto di dichiarare cartelle nel manifesto che possono essere condivise con altri pacchetti dallo stesso editore.

La cartella di archiviazione condivisa presenta i requisiti e le restrizioni seguenti:

• I dati nella cartella di archiviazione condivisa non vengono sottoposti a backup o a roaming.
• L'utente può cancellare il contenuto della cartella di archiviazione condivisa.
• Non è possibile usare la cartella di archiviazione condivisa per condividere i dati tra applicazioni di server di pubblicazione diversi.
• Non è possibile usare la cartella di archiviazione condivisa per condividere i dati tra utenti diversi.
• La cartella di archiviazione condivisa non ha la gestione delle versioni.

Se si pubblicano più applicazioni e si sta cercando un semplice meccanismo per condividere i dati tra di essi, PublisherCacheFolder è un'opzione semplice basata su file system.

SharedAccessStorageManager

SharedAccessStorage Manager viene usato insieme ai servizi app, alle attivazioni del protocollo (ad esempio LaunchUriForResultsAsync) e così via, per condividere StorageFiles tramite token.

FullTrustProcessLauncher

Con la funzionalità runFullTrust, le applicazioni in pacchetto possono avviare processi di attendibilità totale all'interno dello stesso pacchetto.

Per gli scenari in cui le restrizioni dei pacchetti sono un onere o mancano le opzioni IPC, un'applicazione potrebbe usare un processo di attendibilità completa come proxy per interfacciarsi con il sistema e quindi IPC con il processo di attendibilità totale stesso tramite i servizi app o altri meccanismi IPC ben supportati.

LaunchUriForResultsAsync

LaunchUriForResultsAsync viene usato per lo scambio di dati semplice (ValueSet) con altre applicazioni in pacchetto che implementano il contratto di attivazione ProtocolForResults. A differenza dei servizi app, che in genere vengono eseguiti in background, l'applicazione di destinazione viene avviata in primo piano.

I file possono essere condivisi passando token Shared Archiviazione AccessManager all'applicazione tramite ValueSet.

Loopback

Il loopback è il processo di comunicazione con un server di rete in ascolto su localhost (l'indirizzo di loopback).

Per mantenere la sicurezza e l'isolamento della rete, le connessioni loopback per IPC vengono bloccate per impostazione predefinita per le applicazioni in pacchetto. È possibile abilitare le connessioni loopback tra applicazioni in pacchetto attendibili usando funzionalità e proprietà del manifesto.

• Tutte le applicazioni in pacchetto che partecipano alle connessioni loopback dovranno dichiarare la privateNetworkClientServerfunzionalità nei manifesti del pacchetto.
• Due applicazioni in pacchetto possono comunicare tramite loopback dichiarando LoopbackAccessRules all'interno dei manifesti del pacchetto.
  • Ogni applicazione deve elencare l'altra nella proprietà LoopbackAccessRules. Il client dichiara una regola "out" per il server e il server dichiara le regole "in" per i client supportati.

Le applicazioni e i servizi non in pacchetto non dispongono dell'identità del pacchetto, quindi non possono essere dichiarati in LoopbackAccessRules. È possibile configurare un'applicazione in pacchetto per connettersi tramite loopback con applicazioni e servizi non in pacchetto tramite CheckNetIsolation.exe, ma questo è possibile solo per scenari di sideload o debug in cui si dispone dell'accesso locale al computer e si dispone dei privilegi di amministratore.

• Tutte le applicazioni in pacchetto che partecipano alle connessioni loopback devono dichiarare la privateNetworkClientServerfunzionalità nei manifesti del pacchetto.
• Se un'applicazione in pacchetto si connette a un'applicazione o a un servizio non in pacchetto, eseguire CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> per aggiungere un'esenzione di loopback per l'applicazione in pacchetto.
• Se un'applicazione o un servizio non in pacchetto si connette a un'applicazione in pacchetto, eseguire CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> per consentire all'applicazione in pacchetto di ricevere connessioni loopback in ingresso.
  • CheckNetIsolation.exe deve essere in esecuzione continuamente mentre l'applicazione in pacchetto è in ascolto delle connessioni.
  • Il flag -is è stato introdotto in Windows 10 versione 1607 (10.0; Build 14393).

CheckNetIsolation.exe è utile anche per il debug dei problemi di isolamento della rete.

Pipe

Le pipe consentono una comunicazione semplice tra un server pipe e uno o più client pipe.

Le pipe anonime e le pipe denominate sono supportate con i vincoli seguenti:

• Per impostazione predefinita, le pipe denominate nelle applicazioni in pacchetto sono supportate solo tra processi all'interno dello stesso pacchetto, a meno che un processo non sia completamente attendibile.
• Le pipe denominate possono essere condivise tra pacchetti seguendo le linee guida per la condivisione di oggetti denominati.
• Le pipe denominate (nelle app in pacchetto e non in pacchetto) devono usare la sintassi \\.\pipe\LOCAL\ per il nome della pipe.

Registro

L'utilizzo del Registro di sistema per IPC è in genere sconsigliato, ma è supportato per il codice esistente. Le applicazioni in pacchetto possono accedere solo alle chiavi del Registro di sistema a cui dispongono dell'autorizzazione per l'accesso.

In genere, le app desktop in pacchetto (vedere Creazione di un pacchetto MSIX dal codice) sfruttano la virtualizzazione del Registro di sistema in modo che le scritture globali del Registro di sistema siano contenute in un hive privato all'interno del pacchetto MSIX. Ciò consente la compatibilità del codice sorgente riducendo al minimo l'impatto globale del Registro di sistema e può essere usato per IPC tra processi nello stesso pacchetto. Se è necessario usare il Registro di sistema, questo modello è preferibile rispetto alla modifica del Registro di sistema globale.

RPC

Rpc può essere usato per connettere un'applicazione in pacchetto a un endpoint RPC Win32, a condizione che l'applicazione in pacchetto abbia le funzionalità corrette per corrispondere agli elenchi di controllo di accesso nell'endpoint RPC.

Le funzionalità personalizzate consentono agli OEM e agli IHV di definire funzionalità arbitrarie, eseguire ACL con gli endpoint RPC e quindi concedere tali funzionalità alle applicazioni client autorizzate. Per un'applicazione di esempio completa, vedere l'esempio CustomCapability.

Gli endpoint RPC possono anche essere ACL per applicazioni in pacchetto specifiche per limitare l'accesso all'endpoint solo a tali applicazioni senza richiedere il sovraccarico di gestione delle funzionalità personalizzate. È possibile usare l'API DeriveAppContainerSidFromAppContainerName per derivare un SID da un nome di famiglia di pacchetti e quindi ACL l'endpoint RPC con il SID, come illustrato nell'esempio CustomCapability.

Shared Memory

Il mapping dei file può essere usato per condividere un file o una memoria tra due o più processi con i vincoli seguenti:

• Per impostazione predefinita, il mapping dei file nelle applicazioni in pacchetto sono supportati solo tra processi all'interno dello stesso pacchetto, a meno che un processo non sia completamente attendibile.
• I mapping dei file pipe possono essere condivisi tra pacchetti seguendo le linee guida per la condivisione di oggetti denominati.

La memoria condivisa è consigliata per condividere e modificare in modo efficiente grandi quantità di dati.