Share via

Een verpakkingsmodel kiezen voor uw Windows-app

Opmerking

Een nieuwe WinUI 3-app bouwen? U bent al standaard verpakt. Deze pagina is bedoeld voor ontwikkelaars die een expliciete keuze moeten maken, meestal bij het overzetten van een bestaande app, het implementeren op bedrijfscomputers of het toevoegen van Windows-functies aan een app die oorspronkelijk niet is verpakt.

Windows-apps kunnen worden verpakt, uitgepakt of ergens daartussen. De juiste keuze is afhankelijk van twee dingen: hoe u uw app distribueert en welke Windows-functies u nodig hebt.

Beginnen met uw scenario

"Ik ben een indie-ontwikkelaar die publiceert naar de Microsoft Store"

Gebruik een verpakte MSIX-app. Voor de Store is MSIX-verpakking vereist. WinUI 3-apps die in Visual Studio zijn gemaakt, zijn standaard verpakt. U hoeft geen wijzigingen aan te brengen. U krijgt een schone installatie, automatische updates en toegang tot alle functies voor pakketidentiteitsbeveiliging, zoals meldingen en achtergrondtaken.

→ uw verpakte app distribueren

"Ik bouw een bedrijfs-app die is geïmplementeerd via Intune of Configuration Manager"

Start met verpakken; overweeg een externe locatie als u een bestaand installatieprogramma hebt.

  • Als u een nieuwe app bouwt, gebruikt u MSIX. Het integreert op schone wijze met Intune en SCCM/ConfigMgr en biedt u volledige pakketidentiteit.
  • Als u een bestaande app hebt met een eigen installatieprogramma dat u niet kunt vervangen, gebruikt u verpakking met een externe locatie. Dit geeft uw app-pakketidentiteit en toegang tot functies zoals meldingen en achtergrondtaken, zonder dat u de manier waarop of waar u implementeert, hoeft te wijzigen.
  • Als uw app echt geen Windows-identiteitsbeveiligde functies nodig heeft en u de implementatieomgeving onder controle heeft, werkt zonder verpakking, maar de eerste keer dat u probeert meldingen of AI-functies toe te voegen, loopt u tegen een probleem aan.

→ Verpakte apps implementeren (Windows App SDK)
→ Pakketidentiteit verlenen door pakketten met externe locatie te verpakken

"Ik ben een ISV die een directe download verzendt met mijn eigen installatieprogramma"

Gebruik pakketten met een externe locatie (voorheen schaarse pakketten genoemd).

Dit is de zoete plek voor bestaande Win32/WPF/WinForms-apps die worden verzonden via hun eigen installatieprogramma (NSIS, WiX, InstallShield, enzovoort) en deze niet willen vervangen door MSIX. Je registreert een lichtgewicht identiteitspakket naast je bestaande installatieprogramma, je binaire bestanden blijven op hun plaats en je ontgrendelt de volledige set van Windows-functies beperkt door pakketidentiteit.

Uw gebruikers zien geen wijzigingen in de manier waarop ze uw app installeren of bijwerken. U krijgt de Windows-functies; ze krijgen een vertrouwde ervaring.

→ Pakketidentiteit verlenen door pakketten met externe locatie te verpakken
→ een identiteitspakket toevoegen in Visual Studio

"Ik bouw een intern hulpprogramma of ontwikkelhulpprogramma"

Uitpakken is prima, met kanttekeningen.

Uitgepakte apps zijn het eenvoudigst om te bouwen en te implementeren: xcopy, robocopy of een eenvoudig script is alles wat u nodig hebt. De Windows App SDK werkt in uitgepakte apps via NuGet. Maar sommige functies zijn niet beschikbaar en als u later besluit dat u ze nodig hebt, is het opnieuw aanpassen van pakketidentiteiten niet triviaal.

Controleer de onderstaande functietabel in vergelijking met uw routekaart voordat u zich verbindt aan de ongepakte versie. Als meldingen, achtergrondtaken of AI-API's zich aan de horizon bevinden, kunt u overwegen om verpakt te beginnen.

Verpakkingsmodellen in één oogopslag

Model Pakketidentiteit Installer In aanmerking komende winkel Ideaal voor
Verpakt (MSIX) ✅ Ja MSIX vervangt het installatieprogramma ✅ Ja Nieuwe apps, Store-publicatie, ENTERPRISE MDM
Verpakking met externe locatie ✅ Ja Uw bestaande installatieprogramma ❌ Nee Bestaande apps met eigen installatieprogramma, ISV's
Uitgepakt ❌ Nee XCopy/script ❌ Nee Interne hulpprogramma's, ontwikkelhulpprogramma's, eenvoudige scenario's

Functies waarvoor pakketidentiteit is vereist

Deze Windows-functies werken alleen in apps met pakketidentiteit, hetzij via een volledige MSIX-verpakking of -verpakking met externe locatie.

Feature Aantekeningen
App-meldingen (toastbericht) AppNotificationManager vereist pakketidentiteit
achtergrondtaken Registratie vereist pakketidentiteit
Windows AI-API's (PhiSilium, OCR, enzovoort) Voor de meeste Windows AI-API's is pakketidentiteit vereist
Pushmeldingen (WNS) Voor kanaalregistratie is pakketidentiteit vereist
Doel delen Gedeclareerd in pakketmanifest
Aangepaste contextmenu-extensies Gedeclareerd in pakketmanifest
Bestandstypen en protocolkoppelingen Uitgebreide koppelingen vereisen pakketidentiteit
Opstarttaken Pakketidentiteit vereist
App-services Pakketidentiteit vereist

Aanbeveling

Als u niet verpakt bent en E_ILLEGAL_METHOD_CALL of APPMODEL_ERROR_NO_PACKAGE fouten tegenkomt bij het aanroepen van Windows-API's, is dat de pakketidentiteitsvereiste. Zie verpakking met externe locatie als de oplossing met de minste wrijving.

Verpakking met externe locatie

Met pakketten met externe locatie (ook wel sparse-pakketten genoemd) kunt u een klein identiteitspakket naast uw bestaande app registreren, zonder het installatieprogramma, binaire locaties of het updateproces te wijzigen. Het is geïntroduceerd in Windows 10 versie 2004 (build 19041).

U geeft het volgende op:

  • Een pakketmanifest (XML-bestand met een beschrijving van uw app-identiteit)
  • Een ondertekend .msix met alleen het manifest (geen binaire bestanden)

Uw bestaande installatieprogramma registreert dit identiteitspakket en Windows behandelt uw app als pakketidentiteit vanaf dat moment.

Dit verschilt van volledige MSIX-pakketten:

MSIX Externe locatie
Vervangt uw installatieprogramma Ja No
Binaire bestanden in het pakket Ja Nee (extern)
In aanmerking komende winkel Ja No
Pakketidentiteit Ja Ja
Mechanisme voor bijwerken MSIX-update Uw bestaande mechanisme

→ volledig overzicht: Pakketidentiteit verlenen door pakket met externe locatie te verpakken

Frameworkafhankelijke versus zelfstandige implementatie

Apps die gebruikmaken van de Windows App SDK, kiezen los van het verpakkingsmodel hoe ze hun runtime-afhankelijkheden moeten dragen:

  • Frameworkafhankelijk: De Windows App SDK-runtime moet op de computer van de gebruiker worden geïnstalleerd. Kleinere app-footprint; is afhankelijk van de runtime die aanwezig of automatisch is geïnstalleerd.
  • Zelfstandig: alle binaire bestanden van de Windows App SDK worden meegeleverd met uw app. Grotere voetafdruk; geen externe runtime-vereiste. Geschikt voor vergrendelde bedrijfsomgevingen.

→ Zelfstandige apps implementeren

Verwante inhoud

  • Last updated on