Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit onderwerp worden de typen bureaublad-apps beschreven waarvoor u een Windows-app-pakket kunt maken, samen met een aantal gedrag van het besturingssysteem (besturingssysteem) en andere specifieke functies die belangrijk zijn om rekening mee te houden. We gaan dieper in op de volgende items (zoals we zien, is het specifieke gedrag afhankelijk van het type app):
- De installatielocatie en werkmap van uw app (die mogelijk afwijken van wat uw app in het verleden heeft aangenomen).
- Het bestandssysteem en registergedrag van het besturingssysteem.
- Deïnstalleren.
Typen van desktopapplicaties
Er zijn twee typen bureaublad-app die u kunt maken en verpakken. U declareert het type van uw app in het bijbehorende app-pakketmanifest met behulp van het kenmerk uap10:RuntimeBehavior van het toepassingselement :
- Eén type bevat zowel WinUI 3-apps (die gebruikmaken van de Windows App SDK) als Desktop Bridge-apps (Centennial). Met
uap10:RuntimeBehavior="packagedClassicApp"gedeclareerd. - Het andere type vertegenwoordigt andere soorten Win32-apps, inclusief apps die zijn verpakt met externe locatie. Met
uap10:RuntimeBehavior="win32App"gedeclareerd.
UWP-appsuap10:RuntimeBehavior="windowsApp" (Universal Windows Platform) zijn ook verpakt, maar dit onderwerp gaat er niet over.
Vervolgens bepaalt het kenmerk uap10:TrustLevel (van hetzelfde toepassingselement ) of het proces van uw verpakte app al dan niet wordt uitgevoerd in een app-container.
- Een volledig vertrouwde app. Met
uap10:TrustLevel="mediumIL"gedeclareerd. - Een appContainer-app . Met
uap10:TrustLevel="appContainer"gedeclareerd. Wordt uitgevoerd in een lichtgewicht app-container. Zie MSIX appContainer-apps voor meer informatie.
Belangrijk
Zie de documentatie voor deze twee kenmerken in de toepassing voor meer informatie, afhankelijkheden en mogelijkheden. Zie ook dat uap10 is geïntroduceerd in Windows 10, versie 2004 (10.0; Build 19041).
Het doel van het verpakken en app-containers
Het doel van het verpakken van uw app is het verlenen van pakketidentiteit tijdens runtime. Pakketidentiteit is nodig voor bepaalde Windows-functies (zie functies waarvoor pakketidentiteit is vereist). U kunt alle combinaties van app-typen verpakken die hierboven worden beschreven (en daardoor profiteren van pakketidentiteit).
Maar een belangrijk doel van een appContainer-app is om de app-status zoveel mogelijk te scheiden van de systeemstatus, terwijl de compatibiliteit met andere apps behouden blijft. Windows doet dit door tijdens runtime bepaalde wijzigingen te detecteren en om te leiden naar het bestandssysteem en het register (ook wel virtualiseren). We roepen aan wanneer een sectie alleen van toepassing is op gevirtualiseerde apps.
Installatie
App-pakketten worden per gebruiker geïnstalleerd in plaats van systeembreed. De standaardlocatie voor nieuwe pakketten op een nieuwe computer bevindt zich onder C:\Program Files\WindowsApps\<package_full_name>, met het uitvoerbare bestand app_name.exe. Maar pakketten kunnen op andere plaatsen worden geïnstalleerd; De startopdrachten van Visual Studio maken bijvoorbeeld gebruik van $(OutDir)de projectopdrachten.
Na de implementatie worden pakketbestanden gemarkeerd als alleen-lezen en worden ze zwaar vergrendeld door het besturingssysteem (OS). Windows voorkomt dat apps worden gestart als er met deze bestanden wordt geknoeid.
De C:\Program Files\WindowsApps locatie staat bekend als een PackageVolume. Deze locatie is het standaard PackageVolume dat standaard met Windows wordt geleverd; u kunt echter een PackageVolume maken op elk station en elke locatie. Bovendien worden niet alle pakketten geïnstalleerd in een PackageVolume (zie het Visual Studio-voorbeeld hierboven).
Bestandssysteem
Het besturingssysteem ondersteunt verschillende niveaus van bestandssysteembewerkingen voor verpakte bureaublad-apps, afhankelijk van de locatie van de map.
Geoptimaliseerd voor uw apparaat
Om duplicatie van bestanden te voorkomen (om te optimaliseren voor schijfruimte en de bandbreedte te verminderen die nodig is bij het downloaden van bestanden), maakt het besturingssysteem gebruik van één opslag en harde koppeling van bestanden. Wanneer een gebruiker een MSIX-pakket downloadt, wordt het AppxManifest.xml gebruikt om te bepalen of de gegevens in het pakket al op schijf aanwezig zijn vanaf een eerdere pakketinstallatie. Als hetzelfde bestand in meerdere MSIX-pakketten bestaat, slaat het besturingssysteem het gedeelde bestand slechts één keer op de schijf op en maakt het vaste koppelingen van beide pakketten naar het gedeelde bestand. Omdat bestanden in blokken van 64 kB worden gedownload, wordt, zelfs als een gedeelte van een bestand al op de schijf staat, alleen het deel dat verschilt, gedownload. Dit vermindert de bandbreedte die wordt gebruikt voor het downloaden.
AppData-bewerkingen in Windows 10, versie 1903 en hoger
Deze sectie is alleen van toepassing op gevirtualiseerde apps.
Alle zojuist gemaakte bestanden en mappen in de map van de gebruiker AppData (bijvoorbeeld C:\Users\<user_name>\AppData) worden geschreven naar een privélocatie per gebruiker, per app, maar samengevoegd tijdens runtime om op de werkelijke AppData locatie weer te geven. Dat maakt een zekere mate van statusscheiding mogelijk voor artefacten die alleen door de app zelf worden gebruikt; waarmee het systeem deze bestanden kan opschonen wanneer de app wordt verwijderd.
Wijzigingen in bestaande bestanden in de map van AppData de gebruiker zijn toegestaan om een hogere mate van compatibiliteit en interactiviteit tussen apps en het besturingssysteem te bieden. Dit vermindert de 'rot' van het systeem omdat het besturingssysteem op de hoogte is van elke bestands- of mapwijziging die door een app is aangebracht. De scheiding van staat stelt verpakte bureaublad-apps ook in staat door te gaan waar een uitgepakte versie van dezelfde app was gebleven. Houd er rekening mee dat het besturingssysteem geen ondersteuning biedt voor een virtueel bestandssysteem (VFS)-map voor de map van de gebruiker AppData.
AppData-bewerkingen op besturingssystemen ouder dan Windows 10, versie 1903
Deze sectie is alleen van toepassing op gevirtualiseerde apps.
Alle schrijfbewerkingen naar de map van de gebruiker AppData (bijvoorbeeld C:\Users\<user_name>\AppData) - inclusief maken, verwijderen en bijwerken - worden op schrijfmoment gekopieerd naar een privé-locatie per gebruiker, per applicatie. Dat creëert de illusie dat de verpakte app de echte AppData bewerkt wanneer deze daadwerkelijk een privékopie wijzigt. Door schrijfbewerkingen op die manier om te leiden, kan het systeem alle bestandswijzigingen bijhouden die door de app zijn aangebracht. Hierdoor kan het systeem die bestanden opschonen wanneer de app wordt verwijderd, waardoor het systeem 'rot' wordt verminderd en de gebruiker een betere app-verwijderingservaring biedt.
Werkomgeving, en applicatiebestanden
Deze sectie is alleen van toepassing op gevirtualiseerde apps.
Naast het omleiden AppDataworden de bekende mappen van Windows (System32, Program Files (x86)enzovoort) dynamisch samengevoegd met bijbehorende mappen in het app-pakket. Elk pakket bevat een map met de naam VFS in de wortelmap. Leesbewerkingen van mappen of bestanden in de VFS map worden tijdens runtime samengevoegd met hun respectieve systeemeigen tegenhangers. Een app kan bijvoorbeeld als onderdeel van het app-pakket bevatten C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll , maar het bestand lijkt te worden geïnstalleerd op C:\Windows\System32\vc10.dll. Dit onderhoudt de compatibiliteit met desktop-apps die verwachten dat bestanden zich in niet-pakketlocaties bevinden.
Schrijfbewerkingen naar bestanden/mappen in het app-pakket zijn niet toegestaan. Schrijfbewerkingen naar bestanden en mappen die geen deel uitmaken van het pakket worden genegeerd door het besturingssysteem en zijn toegestaan zolang de gebruiker gemachtigd is.
Algemene bestandssysteembewerkingen
In deze korte naslagtabel ziet u algemene bestandssysteembewerkingen en hoe het besturingssysteem deze verwerkt.
| Operatie | Resultaat | Voorbeeld |
|---|---|---|
| Een bekend Windows-bestand of -map lezen of opsommen | Een dynamische samenvoeging van C:\Program Files\<package_full_name>\VFS\<well_known_folder> met de tegenhanger van het lokale systeem. |
Lezen C:\Windows\System32 retourneert de inhoud van C:\Windows\System32 plus de inhoud van C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86. |
Schrijf onder AppData |
Windows 10, versie 1903 en hoger: Nieuwe bestanden en mappen die zijn gemaakt onder de volgende mappen, worden omgeleid naar een privélocatie per gebruiker, per pakket:
AppData locatie. Als het bestand wordt geopend vanaf de werkelijke AppData locatie, vindt er geen virtualisatie voor dat bestand plaats. Bestanden verwijderen onder AppData is toegestaan als de gebruiker de juiste machtigingen heeft.Voor Windows 10, versie 1903: Kopiëren tijdens schrijven naar een locatie per gebruiker, per app. |
AppData is meestal C:\Users\<user_name>\AppData. |
| Schrijven binnen het pakket | Niet toegestaan. Het pakket heeft het kenmerk Alleen-lezen. | Schrijfbewerkingen onder C:\Program Files\WindowsApps\<package_full_name> zijn niet toegestaan. |
| Schrijven buiten het pakket | Toegestaan als de gebruiker machtigingen heeft. | Een schrijfbewerking naar C:\Windows\System32\foo.dll is toegestaan als het pakket geen C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll bevat en de gebruiker machtigingen heeft. |
Verpakte VFS-locaties
Deze sectie is alleen van toepassing op gevirtualiseerde apps.
In deze tabel ziet u waar bestanden die als onderdeel van uw pakket worden verzonden, op het systeem voor de app worden weergegeven. Uw app ziet dat deze bestanden zich in de vermelde systeemlocaties bevinden, terwijl ze zich in werkelijkheid in de omgeleide locaties binnen C:\Program Files\WindowsApps\<package_full_name>\VFS bevinden. De FOLDERID-locaties zijn afkomstig van de CONSTANTEN VAN DE KNOWNFOLDERID .
| Systeemlocatie | Omgeleide locatie (onder [<package_root>]\VFS) | Geldig op architecturen |
|---|---|---|
| FOLDERID_SystemX86 | SystemX86 |
x86, amd64 |
| FOLDERID_System | SystemX64 |
amd64 |
| FOLDERID_ProgramFilesX86 | ProgramFilesX86 |
x86, amd6 |
| FOLDERID_ProgramFilesX64 | ProgramFilesX64 |
amd64 |
| FOLDERID_ProgramFilesCommonX86 | ProgramFilesCommonX86 |
x86, amd64 |
| FOLDERID_ProgramFilesCommonX64 | ProgramFilesCommonX64 |
amd64 |
| FOLDERID_Windows | Windows |
x86, amd64 |
| FOLDERID_ProgramData | Gemeenschappelijk AppData |
x86, amd64 |
| FOLDERID_System\catroot | AppVSystem32Catroot |
x86, amd64 |
| FOLDERID_System\catroot2 | AppVSystem32Catroot2 |
x86, amd64 |
| FOLDERID_System\drivers\etc | AppVSystem32DriversEtc |
x86, amd64 |
| FOLDERID_System\driverstore | AppVSystem32Driverstore |
x86, amd64 |
| FOLDERID_System\logfiles | AppVSystem32Logfiles |
x86, amd64 |
| FOLDERID_System\spool | AppVSystem32Spool |
x86, amd64 |
Registersysteem
Deze sectie (en de subsecties) zijn alleen van toepassing op gevirtualiseerde apps.
App-pakketten bevatten een registry.dat bestand, dat fungeert als het logische (virtuele) equivalent van HKLM\Software in het echte register. Tijdens de uitvoering voegt het virtuele register de inhoud van die hive samen in de systeemeigen hive om één weergave van beide te bieden. Als registry.dat bijvoorbeeld één sleutel Foo bevat, lijkt een lezen van HKLM\Software tijdens uitvoering ook Foo te bevatten (naast alle systeemeigen sleutels).
Hoewel MSIX-pakketten HKLM - en HKCU-sleutels bevatten, worden ze anders behandeld. Alleen sleutels onder HKLM\Software maken deel uit van het pakket; sleutels onder HKCU of andere delen van het register zijn niet. Schrijfbewerkingen naar sleutels of waarden in het pakket zijn niet toegestaan. Schrijfbewerkingen naar sleutels of waarden die geen deel uitmaken van het pakket zijn toegestaan zolang de gebruiker gemachtigd is.
Alle schrijfbewerkingen onder HKCU worden bij schrijven gekopieerd naar een privé, gebruiks- en appspecifieke locatie. Normaal gesproken kunnen verwijderprogramma's HKEY_CURRENT_USER niet opschonen omdat de registergegevens voor afgemelde gebruikers niet zijn gekoppeld en niet beschikbaar zijn.
Alle schrijfbewerkingen worden bewaard tijdens de pakketupgrade en worden alleen verwijderd wanneer de app volledig wordt verwijderd.
Algemene registerbewerkingen
De meeste van deze sectie zijn alleen van toepassing op gevirtualiseerde apps.
In deze korte naslagtabel ziet u algemene registerbewerkingen en hoe het besturingssysteem deze verwerkt.
| Operatie | Resultaat | Voorbeeld |
|---|---|---|
| HKLM\Software lezen of opsommen | Een dynamische samenvoeging van het pakket hive met de tegenhanger van het lokale systeem. | Als registry.dat een enkele sleutel Foo bevat, laat tijdens uitvoeringstijd een lezing van HKLM\Software de inhoud zien van zowel HKLM\Software als HKLM\Software\Foo. |
| Schrijft onder HKCU | Gekopieerd bij het schrijven naar een privélocatie per gebruiker, per app. | Hetzelfde als AppData voor bestanden. |
| Schrijft binnen het pakket. | Niet toegestaan. Het pakket heeft het kenmerk Alleen-lezen. | Schrijfbewerkingen onder HKLM\Software zijn niet toegestaan als er een bijbehorende sleutel/waarde aanwezig is in de pakket hive. |
| Schrijfbewerkingen buiten het pakket | Genegeerd door het besturingssysteem. Toegestaan als de gebruiker machtigingen heeft. | Schrijfbewerkingen onder HKLM\Software zijn toegestaan zolang er geen bijbehorende sleutel/waarde bestaat in de pakket hive en de gebruiker over de juiste toegangsmachtigingen beschikt. |
Deïnstallatie
Deze sectie is alleen van toepassing op gevirtualiseerde apps.
Wanneer een pakket door de gebruiker wordt verwijderd, worden alle bestanden en mappen onder C:\Program Files\WindowsApps\<package_full_name> verwijderd, evenals eventuele omgeleide schrijfbewerkingen naar AppData of het register dat is vastgelegd tijdens het verpakkingsproces.