Paketeringsöversikt

Paketering definierar hur din app installeras, uppdateras och integreras med Windows. WinUI 3-appar är paketerade, medan många skrivbordsappar, till exempel traditionella Win32-program, körs utan paketering. Att välja mellan en paketerad eller uppackad app påverkar de funktioner du kan använda, den distributionsmodell du förlitar dig på och den övergripande upplevelse som dina kunder får.

Anmärkning

Vill du skapa en ny WinUI 3-app? Du är redan förinstallerad som standard. Vägledningen nedan är mest relevant för utvecklare som behöver göra ett explicit val – vanligtvis när de porterar en befintlig app, distribuerar till företagsdatorer eller lägger till Windows funktioner i en app som inte ursprungligen paketerades.

Varför apppaketering är viktigt

Paketerade appar drar nytta av en ren installationsmodell, automatiska uppdateringar och åtkomst till Windows funktioner som kräver paketidentitet – inklusive bakgrundsuppgifter, meddelanden, snabbmenytillägg, delningsmål och andra utökningspunkter. Paketering hjälper också till att säkerställa renare distributioner, tillförlitliga uppdateringar och effektiv distribution via kanaler som Microsoft Store och distributionsverktyg för företag.

Funktioner som kräver paketidentitet

Många Windows funktioner fungerar bara i appar som har paketidentitet, antingen via fullständig MSIX-paketering eller paketering med extern plats (Sparse-paketering). Exempel är bakgrundsuppgifter, push-meddelanden, resursmål, anpassade snabbmenytillägg, manifestbaserad filtyp och protokollassociationer samt Windows AI-API:er.

Den fullständiga listan finns i Funktioner som kräver paketidentitet.

Tips/Råd

Om du inte använder paket och stöter på E_ILLEGAL_METHOD_CALL eller APPMODEL_ERROR_NO_PACKAGE-fel när du anropar Windows API:er är det kravet på paketidentitet. Se paketering med extern lokalisering (Gles förpackning) som lösningen med minst friktion.

Om du vill avgöra vid körning om processen har paketidentitet använder du GetCurrentPackageFullName. Se Är det här en paketerad process? i MSIX-bloggen för kanoniska C++ och C#-exempel.

Snabb överblick över paketeringsmodeller

Modell Paketidentitet Installatör Butikskvalificerad Passar bäst för
Paketerad (MSIX) ✅ Ja MSIX ersätter installationsprogrammet ✅ Ja (MSIX-överföring) Nya appar, Store-publicering, företags-MDM
Paketering med extern läge ✅ Ja Ditt befintliga installationsprogram ✅ Ja (MSI/EXE-inlämning) Befintliga appar med eget installationsprogram, ISV:er
Oförpackad ❌ Nej MSI- eller EXE-installationsprogram (även: XCopy eller skript för distribution som inte är en store-distribution) ✅ Ja (MSI/EXE-inlämning – kräver ett MSI- eller EXE-installationsprogram med stöd för tyst installation) Bred Win32-distribution, interna verktyg

Paketerade appar (MSIX)

Paketerade appar använder MSIX och har paketidentitet, vilket krävs för många Windows utökningspunkter. Med paketidentitet kan Windows på ett tillförlitligt sätt identifiera anroparen av plattforms-API:er, vilket är anledningen till att dessa funktioner är beroende av den.

Paketering med extern plats (gles paketering)

Genom att paketera med extern plats (kallas även för glesa paket) kan du registrera ett litet identitetspaket tillsammans med din befintliga app – utan att ändra installationsprogrammet, binära platser eller uppdateringsprocessen. Den introducerades i Windows 10 version 2004 (version 19041).

Det här är en bra plats för befintliga Win32/WPF/WinForms-appar som levereras via ett eget installationsprogram (NSIS, WiX, InstallShield osv.) och som inte vill ersätta det med MSIX. Du registrerar ett lättvikts-identitetspaket, dina binärfiler stannar där de är och du låser upp hela uppsättningen Windows-funktioner som är låsta bakom paketidentitet.

Förmåga MSIX Extern lokation
Ersätter installationsprogrammet Ja No
Binärfiler i paketet Ja Nej (extern)
Butikskvalificerad Ja (MSIX-inlämning) Ja (MSI/EXE-inlämning)
Paketidentitet Ja Ja
Uppdateringsmekanism MSIX-uppdatering Din befintliga mekanism

komplett genomgång: Bevilja paketidentitet genom att paketera med extern källa

Opacketerade appar

Uppackade appar använder inte MSIX och har inte paketidentitet, vilket innebär att de inte kan komma åt funktionerna som anges ovan.

  • De förblir helt obegränsade gällande API-yta, filsystemets åtkomst, registeråtkomst, utökade privilegier och processmodell.
  • Installation och uppdateringar förlitar sig på .exe, .msi, anpassade installationsprogram, ClickOnce eller xcopy-distribution.

Innan du åtagar dig till packningsfritt kontrollerar du funktionstabellen ovan mot din plan. Om meddelanden, bakgrundsuppgifter eller AI-API:er är i antågande, överväg att börja med en paketerad lösning.

Välj efter scenario

Scenario Rekommenderad modell Detaljer
Indieutvecklare som publicerar på Microsoft Store Paketerad (MSIX) rekommenderas MSIX är den rekommenderade sökvägen – den möjliggör Store-hanterade uppdateringar, differentiella nedladdningar och ren avinstallation. WinUI 3-appar paketeras som standard. Kodsignering hanteras kostnadsfritt av Store. → Distribuera din paketerade app

Win32-appar med ett befintligt MSI- eller EXE-installationsprogram kan också publicera till Store via MSI/EXE-inlämningsvägen, men Store skickar inte uppdateringar till befintliga användare – uppdateringar måste hanteras av appen eller installationsprogrammen.
Enterprise-appen distribuerad via Intune eller Configuration Manager Förpackad eller extern lagringsplats för befintliga installationsprogram Nya appar bör använda MSIX. Befintliga appar med ett eget installationsprogram kan använda paketering med extern platsangivelse. Kodsignering: använda ett självsignerat certifikat (betrott via Intune, Grupprincip eller Configuration Manager) eller Azure artefaktsignering (Tidigare Betrodd Signering). → Distribuera paketerade appar
ISV skickar en direkt nedladdning med ett eget installationsprogram Paketering med extern lokalisering Registrera ett enkelt identitetspaket tillsammans med ditt befintliga installationsprogram. Kodsignering: ett CA-betrott certifikat krävs för icke-Store-distribution. Azure Artifact Signing (tidigare Trusted Signing) är det rekommenderade alternativet med lägre kostnad. → Bevilja paketidentitet

Alternativt kan du skicka in ditt befintliga installationsprogram till Store genom MSI/EXE-inskickningsväg.
Internt verktyg eller utvecklarverktyg Unpackaged Enklast att skapa och distribuera. Windows App SDK fungerar via NuGet, men vissa funktioner är inte tillgängliga.

Tips/Råd

Krav och kostnader för kodsignering varierar beroende på distributionssökväg. En fullständig uppdelning av dina alternativ finns i Kodsigneringsalternativ för Windows apputvecklare.

Ramverksberoende eller fristående distribution

Separat från paketeringsmodellen väljer appar som använder Windows App SDK hur de ska bära sina körningsberoenden: ramverksberoende (Windows App SDK-körningen är installerad på användarens dator) eller fristående (alla Windows App SDK binärfiler levereras med din app). Det här valet är oberoende av förpackning.

En fullständig jämförelse och distributionsvägledning finns i Windows App SDK distributionsöversikt.

Kom igång med MSIX

Om du skapar en Win32-skrivbordsapp (kallas ibland för en klassisk skrivbordsapp) eller en .NET app – inklusive Windows Presentation Foundation (WPF) och Windows Forms (WinForms) – kan du paketera och distribuera din app med MSIX.

Migrera till MSIX från äldre installationsprogram

Om din app för närvarande använder ett äldre installationsprogram kan du migrera till MSIX för att få ren installation/avinstallation, automatiska uppdateringar, Butiksdistribution och paketidentitet. Migreringssökvägen beror på din aktuella installationsteknik och om du har åtkomst till källkoden.

Nuvarande installationsprogram Rekommenderad migreringssökväg Krävs källkod?
MSI (Windows Installer) Använd MSIX-paketeringsverktyget för att konvertera MSI direkt till MSIX. Hanterar de flesta MSI-mönster, inklusive anpassade åtgärder. No
ClickOnce (.NET) Återskapa från källan med hjälp av Visual Studio MSIX-paketeringsprojekt. ClickOnce auto-update kan ersättas med Store-uppdateringar eller App Installer. Ja
InstallShield/Avancerat installationsprogram Använd MSIX-paketeringsverktyget för att avbilda en installation på en ren virtuell dator. Komplexa anpassade åtgärder kan behöva åtgärdas manuellt i paketredigeraren. No
Inno Setup / NSIS Använd MSIX-paketeringsverktygets VM-baserade avbildningsarbetsflöde. Kör EXE-installationsprogrammet i verktygets rena miljö. No
App-V (virtuella paket) Konvertera direkt med msix-paketeringsverktyget – det stöder App-V 5.x-paket som indata. No
MSIX med nödvändiga ändringar Använd Package Support Framework för att tillämpa körningskorrigeringar (fil-/registeromdirigering) utan att ändra appkoden. No

Tips/Råd

För appar som har komplexa installationsprogram med kerneldrivrutiner, tjänster som körs som SYSTEM eller datoromfattande COM-registreringar som MSIX inte stöder, bör du överväga MSIX med extern plats (paketerad med extern plats). Detta ger dig paketidentitet för Windows funktioner när du använder ett traditionellt installationsprogram för komponenter som kräver förhöjd åtkomst. Se Bevilja paketidentitet genom att paketera med extern lokalisering.

Viktiga överväganden

  • Testa på en ren virtuell dator – MSIX-paketeringsverktyget samlar in alla ändringar under installationen. Kör den på en ren Windows avbildning för att undvika att samla in orelaterade systemändringar.
  • Package Support Framework – Om din konverterade app har körningsproblem (antaganden om filsökväg, registerskrivningar till HKLM) kan Package Support Framework åtgärda dessa utan att ändra källan.
  • Sida vid sida med äldre installationsprogram – Du kan distribuera MSIX-versionen tillsammans med det äldre installationsprogrammet under övergången. Planera en explicit inställning/datamigrering (till exempel importera vid första körningen) eftersom paketidentitet och lagringsplatser skiljer sig mellan MSIX- och MSI/EXE-installationer.

Andra installationstekniker

Relaterat innehåll

  • Last updated on