Interprocesskommunikation (IPC)

Det här avsnittet beskriver olika sätt att utföra kommunikation mellan olika processer (IPC) mellan Windows App SDK skrivbordsappar och andra Win32-program. Eftersom Windows App SDK skrivbordsappar körs som Win32-processer med fullständigt förtroende har de direkt åtkomst till alla IPC-mekanismer på os-nivå. Vissa mekanismer har ytterligare krav när appar paketeras med MSIX, enligt beskrivningen i avsnitten nedan.

Apptjänster

Apptjänster gör det möjligt för applikationer att tillhandahålla tjänster som accepterar och returnerar egenskapssamlingar med primitiva värden (ValueSet) i bakgrunden. Rika objekt kan skickas, om de serialiseras.

Apptjänster kan köras antingen utanför processen som en bakgrundsaktivitet eller i processen i förgrundsappen.

Apptjänster används bäst för att dela små mängder data där svarstid i nära realtid inte krävs.

COM

COM är ett distribuerat objektorienterat system för att skapa binära programvarukomponenter som kan interagera och kommunicera. Som utvecklare använder du COM för att skapa återanvändbara programvarukomponenter och automatiseringslager för ett program. COM-komponenter kan vara i process eller ur process och de kan kommunicera via en klient- och servermodell . Com-servrar utan process har länge använts som ett sätt att kommunicera mellan objekt.

Paketerade program med funktionen runFullTrust kan registrera COM-servrar utan process för IPC via paketmanifestet. Detta kallas paketerad COM.

Windows App SDK skrivbordsappar körs som fullständiga förtroendeprocesser, så att de även kan registrera och använda COM-servrar direkt via Windows Registry, precis som traditionella Win32-program.

Filesystem

BroadFileSystemAccess

Paketerade program kan utföra IPC med hjälp av det breda filsystemet genom att deklarera den broadFileSystemAccess begränsade funktionen. Den här funktionen ger Windows.Storage-API:er och Win32-FromApp-API:er åtkomst till det allmänna filsystemet.

Som standard är IPC via filsystemet för paketerade program begränsat till de andra mekanismerna som beskrivs i det här avsnittet.

PublisherCacheFolder

Med PublisherCacheFolder kan paketerade program deklarera mappar i sitt manifest som kan delas med andra paket av samma utgivare.

Den delade lagringsmappen har följande krav och begränsningar:

• Data i den delade lagringsmappen säkerhetskopieras inte eller flyttas.
• Användaren kan rensa innehållet i den delade lagringsmappen.
• Du kan inte använda den delade lagringsmappen för att dela data mellan program från olika utgivare.
• Du kan inte använda den delade lagringsmappen för att dela data mellan olika användare.
• Den delade lagringsmappen har inte versionshantering.

Om du publicerar flera program och letar efter en enkel mekanism för att dela data mellan dem är PublisherCacheFolder ett enkelt filsystembaserat alternativ.

Rör

Rör möjliggör enkel kommunikation mellan en rörserver och en eller flera rörklienter.

Anonyma rör och namngivna rör stöds med följande begränsningar:

• Som standard stöds namngivna rör i paketerade appar endast mellan processer inom samma paket, om inte en process har fullständig behörighet.
• Namngivna rör kan delas mellan paket enligt riktlinjerna för delning av namngivna objekt.
• Namngivna rör i paketerade appar bör inkluderas LOCAL\ i pipe-namnet (till exempel \\.\pipe\LOCAL\<pipename>). Segmentet LOCAL\ omfångsbegränsar röret till anroparens inloggningssession och krävs för MSIX-paketerade appar. När du använder .NET API:er som NamedPipeServerStreamskickar du bara LOCAL\<pipename> delen – prefixet \\.\pipe\ hanteras internt.

Windows App SDK-skrivbordsappar körs som processer med fullständig behörighet, så de kan skapa och använda namngivna rör utan begränsningen till samma paket. Men om du kommunicerar med en annan paketerad app som inte har fullt förtroende gäller begränsningarna ovan fortfarande.

Exempel på namngiven pipe (C#)

Följande exempel demonstrerar en komplett server och klient för namngiven pipe som två konsolprogram. Eftersom Windows App SDK-skrivbordsappar är fullt betrodda processer fungerar IPC via namngivna pipes utan några särskilda behörigheter eller manifestposter.

Om du vill prova det här exemplet skapar du två konsolappprojekt (mål net8.0-windows med ImplicitUsings aktiverat) och kör servern först och sedan klienten i en separat terminal.

Pipe server – skapar en namngiven pipe och ekar meddelanden tillbaka till klienten:

using System.Text;

string PipeName = @"LOCAL\WinAppSdkIpcDemo";

Console.WriteLine("Named Pipe Server");
Console.WriteLine($"  Process ID: {Environment.ProcessId}");
Console.WriteLine($"  User:       {Environment.UserName}");
Console.WriteLine($"  Pipe:       \\\\.\\pipe\\{PipeName}");
Console.WriteLine();

using var server = new System.IO.Pipes.NamedPipeServerStream(
    PipeName,
    System.IO.Pipes.PipeDirection.InOut,
    maxNumberOfServerInstances: 1,
    System.IO.Pipes.PipeTransmissionMode.Message,
    System.IO.Pipes.PipeOptions.Asynchronous);

Console.WriteLine("Waiting for client...");
await server.WaitForConnectionAsync();
Console.WriteLine("Client connected!");

byte[] buffer = new byte[4096];

while (server.IsConnected)
{
    try
    {
        int bytesRead = await server.ReadAsync(buffer);
        if (bytesRead == 0) break;

        string received = Encoding.UTF8.GetString(buffer, 0, bytesRead);
        Console.WriteLine($"  Received: \"{received}\"");

        if (received.Equals("QUIT", StringComparison.OrdinalIgnoreCase))
            break;

        // Echo the message back with the server's process ID
        string reply = $"Echo from PID {Environment.ProcessId}: {received}";
        await server.WriteAsync(Encoding.UTF8.GetBytes(reply));
        await server.FlushAsync();
    }
    catch (IOException)
    {
        break;
    }
}

Console.WriteLine("Done.");

Pipe-klient – ansluter till servern och skickar användarindata:

using System.Text;

string PipeName = @"LOCAL\WinAppSdkIpcDemo";

Console.WriteLine("Named Pipe Client");
Console.WriteLine($"  Process ID: {Environment.ProcessId}");
Console.WriteLine();

using var client = new System.IO.Pipes.NamedPipeClientStream(
    serverName: ".",
    pipeName: PipeName,
    System.IO.Pipes.PipeDirection.InOut,
    System.IO.Pipes.PipeOptions.Asynchronous);

Console.WriteLine("Connecting...");
await client.ConnectAsync(timeout: 5000);
client.ReadMode = System.IO.Pipes.PipeTransmissionMode.Message;
Console.WriteLine("Connected! Type messages (or QUIT to exit):");

byte[] buffer = new byte[4096];

while (true)
{
    Console.Write("> ");
    string? input = Console.ReadLine();
    if (string.IsNullOrEmpty(input)) continue;

    await client.WriteAsync(Encoding.UTF8.GetBytes(input));
    await client.FlushAsync();

    if (input.Equals("QUIT", StringComparison.OrdinalIgnoreCase))
        break;

    int bytesRead = await client.ReadAsync(buffer);
    string response = Encoding.UTF8.GetString(buffer, 0, bytesRead);
    Console.WriteLine($"  <- {response}");
}

Console.WriteLine("Done.");

När du kör båda applikationerna skickar klienten meddelanden som servern skickar tillbaka, vilket bekräftar kommunikationen mellan två skrivbordsprocesser med fullständig behörighet utan att någon särskild konfiguration behövs.

Registry

Registeranvändning för IPC rekommenderas vanligtvis inte, men det stöds för befintlig kod. Paketerade program kan endast komma åt registernycklar som de har behörighet att komma åt.

Paketerade skrivbordsappar (se Skapa ett MSIX-paket från koden) utnyttjar registervirtualisering så att globala registerskrivningar finns i en privat hive i MSIX-paketet. Detta möjliggör källkodskompatibilitet samtidigt som den globala registerpåverkan minimeras och kan användas för IPC mellan processer i samma paket. Om du måste använda registret är den här modellen att föredra jämfört med att manipulera det globala registret.

Fjärrprocedureanrop (RPC)

RPC kan användas för att ansluta ett paketerat program till en Win32 RPC-slutpunkt, förutsatt att det paketerade programmet har rätt funktioner för att matcha ACL:erna på RPC-slutpunkten.

Anpassade funktioner gör det möjligt för OEM-tillverkare och IHV:er att definiera godtyckliga funktioner, ACL sina RPC-slutpunkter med dem och sedan bevilja dessa funktioner till auktoriserade klientprogram. Ett fullständigt exempelprogram finns i CustomCapability-exemplet .

RPC-slutpunkter kan också kopplas till specifika paketerade program för att begränsa åtkomsten till slutpunkten till bara dessa program utan att kräva hanteringskostnader för anpassade funktioner. Du kan använda Api:et DeriveAppContainerSidFromAppContainerName för att härleda ett SID från ett paketfamiljenamn och sedan ACL RPC-slutpunkten med SID enligt exemplet CustomCapability .

Delat minne

Filmappning kan användas för att dela en fil eller ett minne mellan två eller flera processer med följande begränsningar:

• Som standard stöds filmappningar i paketerade applikationer endast mellan processer inom samma paket, om inte en process körs med fullständig behörighet.
• Filmappningar kan delas mellan paket enligt riktlinjerna för delning av namngivna objekt.

Windows App SDK skrivbordsappar körs som fullständiga förtroendeprocesser, så att de kan skapa och använda mappningar för delade minnesfiler utan begränsning. När du kommunicerar med en annan paketerad app som inte har fullt förtroende använder du ACL-metoden som beskrivs i delning av namngivna objekt.

Delat minne rekommenderas för att effektivt dela och manipulera stora mängder data.

Loopback

Loopback är processen där man kommunicerar med en nätverksserver som lyssnar på localhost (loopback-adressen).

För att upprätthålla säkerhet och nätverksisolering blockeras loopback-anslutningar för IPC som standard för paketerade program. Du kan aktivera loopback-anslutningar mellan betrodda paketerade program med hjälp av funktioner och manifestegenskaper.

• Alla paketerade program som deltar i loopback-anslutningar måste deklarera privateNetworkClientServer funktionen i sina paketmanifest.
• Två paketerade program kan kommunicera via loopback genom att deklarera LoopbackAccessRules i sina paketmanifest.
  • Varje program måste visa den andra i sin LoopbackAccessRules. Klienten deklarerar en "out"-regel för servern, och servern deklarerar "in"-regler för de klienter som den har stöd för.

Uppackade program och tjänster har inte paketidentitet, så de kan inte deklareras i LoopbackAccessRules. Du kan konfigurera en paketerad applikation så att den ansluter via loopback till opaketerade applikationer och tjänster via CheckNetIsolation.exe, men detta är endast möjligt i scenarier för sideladdning eller felsökning där du har lokal åtkomst till datorn och administratörsbehörighet.

• Om ett paketerat program ansluter till ett uppackat program eller en tjänst kör du CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME> för att lägga till ett loopback-undantag för det paketerade programmet.
• Om ett opaketerat program eller en tjänst upprättar en anslutning till ett paketerat program kör du CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME> så att det paketerade programmet kan ta emot inkommande loopback-anslutningar.
  • CheckNetIsolation.exe måste köras kontinuerligt medan det paketerade programmet lyssnar efter anslutningar.

Välja en IPC-mekanism

I följande tabell sammanfattas IPC-mekanismerna och deras bästa användningsfall:

Relaterat innehåll

• Dela namngivna objekt
• Översikt över Windows App SDK
• Översikt över MSIX-paketering