Dela via

Distributionsarkitektur och översikt för ramverksberoende appar

I den här artikeln beskrivs en arkitektur på hög nivå för Windows App SDK-distribution. Begreppen nedan gäller främst för ramverksberoende appar i Windows App SDK. En ramverksberoende app är beroende av att Windows App SDK-körningen finns på måldatorn.

Det finns två huvudsakliga alternativ för att distribuera en ramverksberoende app:

Appdistributionssätt Kravspecifikation
Förpackade – Måste deklarera beroende av Framework-paketet i paketmanifestet.
– Distributions-API krävs för Microsoft Store-distribuerade appar och rekommenderas för icke-Store-distribuerade appar för att säkerställa att körningsberoenden installeras.
Paketerad med extern lokalisering eller utan förpackning – Måste distribuera runtime-miljön antingen med installationsprogrammet eller genom att installera nödvändiga MSIX-paket direkt.
– Ytterligare körtidskrav: Måste initiera åtkomsten till Windows App SDK-körtiden via Bootstrap-API:t.

Mer information om dessa krav finns i följande artiklar:

Viktiga termer

I följande avsnitt definieras viktiga termer för Windows App SDK-distribution och ytterligare information om några av dessa paket.

Begrepp Definition
Windows App SDK-körmiljö De MSIX-paket som krävs av en app för att använda Windows App SDK. Dessa paket omfattar: Framework, Main, Singleton och DDLM. Beroende på vilka funktioner som används och din appdistributionsmetod behöver du en viss uppsättning paket på måldatorn.
Framework-paket Innehåller binärfiler som används vid körning av appar (de flesta Windows App SDK-funktioner). Ramverket innehåller en bootstrapper-komponent som gör att appar automatiskt kan installera den senaste versionen av Windows App SDK, som uppdateras regelbundet.
Huvudpaket Paket som innehåller bakgrundsuppgifter för att hålla reda på dynamiska beroenden och möjliggör automatiska uppdateringar av Framework-paketet från Microsoft Store.
Singleton-paket Innehåller bakgrundsuppgifter, tjänster, apptillägg och andra komponenter som inte ingår i Framework-paketet, till exempel push-meddelanden. Det här är vanligtvis en enda långvarig process som förmedlas mellan appar.
DDLM-paket (Dynamic Dependency Lifetime Manager) Förhindrar operativsystemet från att utföra serviceuppdateringar av MSIX-paketen medan en app som är paketerad för extern plats eller en app utan paket används.
Bootstrapper En binär fil som är app-lokal används av appar som är paketerade med externa platser och uppackade appar, för att lokalisera och ladda den bästa matchningen av Windows App SDK-versionen när det behövs av appen.
Försörjning Processen att installera och registrera paket (inklusive filer och registernycklar) systemomfattande för att eliminera behovet av upprepad installation av de andra användarna. Det kan göras antingen som en del av operativsystemet eller under installationen av en app.
Installatör Refererar till .exe installationsprogrammet som distribuerar paketen Framework, Main, Singleton och DDLM.
MSIX Modern installationsteknik som gör att användarna på ett säkert sätt kan installera en app per användare, direkt från Microsoft Store eller en webbplats. På enterprise- eller delade datorer kan appar installeras för alla användare via PowerShell och MDM.

Framework-paket

När du skapar en app som använder Windows App SDK refererar din app till en uppsättning Windows App SDK-körningskomponenter som distribueras till slutanvändare via ett ramverkspaket. Ramverkspaketet gör det möjligt för appar att komma åt Windows App SDK-komponenter via en enda delad källa på användarens enhet, i stället för att paketera dem i apppaketet. Ramverkspaketet har också egna resurser, till exempel DLL:er och API-definitioner (COM- och Windows Runtime-registreringar). Dessa resurser körs i appens kontext, så de ärver appens funktioner och behörigheter och hävdar inte några egna funktioner eller privilegier. Mer information om beroenden för ramverkspaket finns i MSIX-ramverkspaket och dynamiska beroenden.

Windows App SDK-ramverkspaketet är ett MSIX-paket som distribueras till slutanvändare via Microsoft Store. Det kan enkelt och snabbt uppdateras med serviceutgåvor, vilket kan innefatta säkerhets- och tillförlitlighetskorrigeringar. Alla ramverksberoende appar som använder Windows App SDK har ett beroende av en delad instans av ramverkspaketet, enligt följande diagram.

Diagram över hur appar får åtkomst till Windows App SDK-ramverkspaketet

När en ny version av Windows App SDK-ramverkspaketet hanteras uppdateras alla ramverksberoende appar till den nya versionen utan att de själva behöver omdistribuera en kopia. Windows uppdaterar till den senaste versionen av ramverk när de släpps, och appar refererar automatiskt till den senaste versionen av ramverkspaketet vid nylansering. Äldre ramverkspaketversioner tas inte bort från systemet förrän de inte längre körs eller används aktivt av appar i systemet.

Diagram över hur appar får uppdateringar av Windows App SDK-ramverkspaketet

Eftersom appkompatibilitet är viktigt för Microsoft och för appar som är beroende av Windows App SDK följer Windows App SDK-ramverkspaketet semantiska version 2.0.0- regler. Det innebär att när vi har släppt version 1.0 av Windows App SDK garanterar Windows App SDK-ramverkspaketet kompatibilitet mellan mindre ändringar och korrigeringsversionsändringar, och icke-bakåtkompatibla ändringar sker endast mellan viktiga versionsuppdateringar.

Singleton-paket

Det singleton-paketet säkerställer att en enda tidskrävande process kan hantera tjänster som används i flera appar, som kan köras på olika versioner av Windows App SDK.

Windows App SDK-singleton krävs för att aktivera push-meddelanden för uppackade appar och paketerade Win32-program med Windows-versioner under 20H1, som inte kan stödjas av den befintliga UWP-PushNotificationTrigger och ToastNotificationActionTrigger-klassen. Framtida Windows App SDK-funktioner som inte kan stödjas av Framework-paketet läggs till i Singleton-paketet.

Ytterligare krav för opacketerade appar

Uppstartare

Den bootstrapper är ett bibliotek som måste ingå i din app, oavsett om den är paketerad med extern plats eller opaketerad. Det tillhandahåller bootstrapper-API:et (se Använd Windows App SDK-körningen för appar som paketeras med extern plats eller packas upp), vilket gör att uppackade appar kan utföra dessa viktiga uppgifter:

  • Initiera DDLM (Dynamic Dependency Lifetime Manager) för Windows App SDK-ramverkspaketet.
  • Hitta och läs in Windows App SDK-ramverkspaketet till appens paketdiagram.

För att utföra dessa uppgifter använder nuget-paketet modulinitierare för att koppla upp bootstrappern åt dig. Ange bara <WindowsPackageType>None</WindowsPackageType> i projektfilen. Om du vill ha kontroll över initieringen i avancerade scenarier kan du anropa bootstrapper-API:et direkt i appens startkod (se Självstudie: Använd bootstrapper-API:et i en externt paketerad app eller en uppackad app som använder Windows App SDK) så att systemet kan initieras korrekt för den uppackade appen. Din app måste använda bootstrapper-API:et innan den kan använda Windows App SDK-funktioner som WinUI, applivscykel, MRT Core och DWriteCore.

Bootstrapper-biblioteket i Windows App SDK 1.0-versionen innehåller:

  • Microsoft.WindowsAppRuntime.Bootstrap.dll (C++ och C#)
  • Microsoft.WindowsAppRuntime.Bootstrap.Net.dll (C#-omslutning)

Dynamic Dependency Livscykelhanterare (DDLM)

Syftet med DDLM är att förhindra underhåll av Windows App SDK-ramverkspaketet när det används av en uppackad app. Den innehåller en server som bootstrappern måste initiera tidigt under appens start för att tillhandahålla denna funktion.

Det finns en DDLM för varje version och arkitektur i Windows App SDK-ramverkspaketet. Det innebär att du på en x64 dator kan ha både en x86 och en x64 version av DDLM för att stödja appar i båda arkitekturerna.

Ytterligare krav