Windows App SDK üzembe helyezés áttekintése

A Windows App SDK kétféleképpen helyezheti üzembe:

  • keretrendszerfüggő. Az alkalmazás attól függ, hogy a Windows App SDK futtatókörnyezet és/vagy a keretrendszercsomag jelen van-e a célszámítógépen. A keretrendszertől függő üzembe helyezés a Windows App SDK alapértelmezett üzembe helyezési módja a gépi erőforrások hatékony használatához és a használhatósághoz.
  • önálló. Az alkalmazás magában hordozza a Windows App SDK függőségeit, így nincs szükség külön futtatókörnyezet telepítésére a célszámítógépen.

Ez a témakör a csomagolt alkalmazást, a külső hellyel rendelkező csomagolt alkalmazást és a csomagolatlan alkalmazást is használja. Ezeknek a kifejezéseknek a magyarázatáért tekintse meg az üzembe helyezés áttekintését.

Keretrendszerfüggő üzembe helyezése Önálló telepítés
Előnye Kis üzembe helyezés. Csak az ön alkalmazása és annak többi függősége kerül elosztásra. A Windows App SDK futtatókörnyezetet és a keretrendszercsomagot automatikusan telepítik a keretrendszerfüggő alkalmazások, amelyek csomagolva vannak, vagy a Windows App SDK futtatókörnyezet telepítőjének részeként olyan keretrendszerfüggő alkalmazások, amelyek külső helyre vannak csomagolva vagy csomagolatlanok.

Szervizelhető. A Windows App SDK karbantartási frissítései automatikusan települnek a Windows App SDK-keretrendszer csomagon keresztül anélkül, hogy az alkalmazás bármilyen műveletet igényel.
Control Windows App SDK verzió. Ön határozza meg, hogy a Windows App SDK melyik verziója legyen üzembe helyezve az alkalmazással. A Windows App SDK karbantartási frissítései csak akkor lesznek hatással az alkalmazásra, ha újraépíti és terjeszti azt.

Elkülönítve más alkalmazásoktól. Az alkalmazások és a felhasználók nem távolíthatják el a Windows App SDK-függőséget a teljes alkalmazás eltávolítása nélkül.

Xcopy üzembe helyezése. Mivel a Windows App SDK függőségeket az alkalmazás hordozta, üzembe helyezheti az alkalmazást úgy, hogy egyszerűen átmásozza a build kimenetét, további telepítési követelmények nélkül.
Hátrányai További telepítési függőségek. A Windows App SDK futtatókörnyezet és/vagy keretrendszercsomag telepítését igényli, amely összetettebbé teheti az alkalmazástelepítést.

Megosztott függőségek. A megosztott függőségek eltávolításának kockázata. A megosztott összetevőket eltávolító alkalmazások vagy felhasználók hatással lehetnek a függőséget megosztó más alkalmazások felhasználói élményére.

Kompatibilitási kockázat. Fennáll annak a kockázata, hogy a Windows App SDK karbantartási frissítései kompatibilitástörő változásokat vezetnek be. Bár a karbantartási frissítéseknek visszamenőleges kompatibilitást kell biztosítaniuk, lehetséges, hogy regressziókat vezetnek be.
Nagyobb üzembe helyezések (csak csomagolatlan alkalmazások). Mivel az alkalmazás tartalmazza a Windows App SDK, a szükséges letöltési méret és merevlemez-terület nagyobb, mint a keretrendszertől függő verziók esetében.

Teljesítmény (csak csomagolatlan alkalmazások). Lassabban töltődik be, és több memóriát használ, mivel a kódlapokat nem osztják meg más alkalmazásokkal.

Nem használható. Az alkalmazással elosztott Windows App SDK verzió csak az alkalmazás új verziójának kiadásával frissíthető. Önnek kell integrálnia a Windows App SDK karbantartási frissítéseit az alkalmazásba.

Lásd még: Az első WinUI 3 projekt és A Windows App SDK használata meglévő projektben.

Note

PublishSingleFile Az (egyfájlos EXE) támogatott a csomagolatlan, önálló WinUI 3-alkalmazásokhoz (Windows App SDK 1.5-ös és újabb verziókhoz). A csomagolt alkalmazások és a keretrendszerfüggő alkalmazások nem támogatottak PublishSingleFile. A szükséges MSBuild tulajdonságokért lásd az egyfájlos EXE fájlt.

További információ a keretrendszerfüggő üzembe helyezésről

Mielőtt konfigurálja a keretrendszerfüggő alkalmazását az üzembe helyezéshez, ismerje meg, hogy milyen függőségeket vesz igénybe az alkalmazása a Windows App SDK használatakor, tekintse át a Windows App SDK telepítési architektúráját.

Csomagolt alkalmazások

Ha a keretrendszertől függő, csomagolt alkalmazás mellett döntött (lásd: Deployment áttekintése), akkor az alábbi útmutatást követve telepítheti a Windows App SDK futtatókörnyezetet az alkalmazással:

Csomagolás külső helyekkel vagy csomagolatlan alkalmazásokkal

Ha úgy döntött, hogy külső hellyel rendelkező, keretrendszertől függő csomagolt alkalmazást vagy keretrendszerfüggő csomagolatlan alkalmazást választ (lásd: Deployment áttekintés), akkor az alábbiakban bemutatjuk, hogyan helyezheti üzembe a Windows App SDK futtatókörnyezetet az alkalmazással:

További információ az önálló üzembe helyezésről

Tekintse meg a Windows App SDK önálló alkalmazások üzembehelyezési útmutatójában.

Note

PublishSingleFile Az (egyfájlos EXE) használatához az alkalmazásnak csomagolatlannak és önállónak kell lennie. A szükséges MSBuild tulajdonságok teljes listáját az egyfájlos EXE fájlban találja.

A Windows App SDK inicializálása

A Windows App SDK inicializálásának módja attól függ, hogy becsomagolja-e az alkalmazást, és hogyan, és hogy milyen módon helyezze üzembe az Windows App SDK futtatókörnyezethez képest. Használja az alábbi szakaszt, amely az alkalmazásra vonatkozik.

Csomagolt alkalmazások

Az alkalmazás üzembe helyezése Hogyan inicializáljunk
Keretrendszerfüggő Lásd: Hívd meg a Deployment API-t.
Önálló Nincs szükség inicializálásra.

Csomagolatlan alkalmazások és külső helyre csomagolt alkalmazások

Az alkalmazás üzembe helyezése Hogyan inicializáljunk
Keretrendszerfüggő Lásd: A bootstrapper API használata külső helyen vagy csomagolatlancsomagolt alkalmazásban.
Önálló Lásd: Az automatikus UndockedRegFreeWinRT-támogatásletiltása (vagy engedélyezése).

Architektúrával kapcsolatos szempontok (x64, ARM64)

Az alkalmazás üzembe helyezésekor bináris fájlokat kell tartalmaznia a felhasználók számára szükséges processzorarchitektúrákhoz. Ez a keretrendszertől függő és az önálló üzembe helyezési módokra is vonatkozik.

ARM64-támogatás

Windows ARM-eszközökön (beleértve az Surface Pro X-et, a Surface Pro 11-et és a Copilot+ PCs) natív módon futtatja az ARM64-et. Bár az x64-emuláció Windows 11 ARM64-eszközökön érhető el, a natív ARM64 bináris fájlok jobb teljesítményt és akkumulátor-üzemidőt biztosítanak – és akkor ajánlott, ha a legjobb élményt szeretné az eszközön futó AI-számítási feladatokhoz a Copilot+ PCs.

Natív ARM64-üzembe helyezés

  • MSIX-csomagok – Hozzon létre egy olyan csomagot .msixbundle , amely mindkettőt x64 és ARM64 architektúrát tartalmaz. Visual Studio ezeket automatikusan generálja, amikor több platformra készül. Az Áruház és az Alkalmazástelepítő a telepítéskor a megfelelő architektúrát választja ki.

  • Önálló közzététel – Adja meg az egyes architektúrák futtatókörnyezet-azonosítóját (RID):

    dotnet publish -c Release -r win-x64 --self-contained true
    dotnet publish -c Release -r win-arm64 --self-contained true
    
  • C++/WinRT — Hozzon létre külön konfigurációkat a Visual Studio-megoldásban a(z) x64 és ARM64 számára.

  • Keretrendszerfüggő alkalmazások – A Windows App SDK futtatókörnyezet telepítőjének használatakor győződjön meg arról, hogy a megfelelő architektúraspecifikus telepítőt adja meg. A Windows App SDK külön telepítőket szállít az x64-hez és az ARM64-hez.

Arm64EC – fokozatos migrálás nagy C/C++ kódbázisokhoz

Ha az alkalmazás nagy natív (C/C++) kódbázissal rendelkezik, előfordulhat, hogy az ARM64 teljes újrafordítása egyetlen lépésben sem praktikus. Az Arm64EC (Emulation Compatible) lehetővé teszi az x64- és ARM64-kód keverését ugyanabban a folyamatban. A teljesítmény szempontjából kritikus modulokat a natív ARM64-re fordíthatja, míg a fennmaradó x64-modulok emuláció alatt futnak – mindezt egyetlen bináris fájlban.

Approach Legjobb a számára Kompromisszum
Teljes ARM64 újrafordítás Tiszta .NET alkalmazások, kis C++ projektek Legjobb teljesítmény; minden függőségnek ARM64-kompatibilisnek kell lennie
Arm64EC Nagyméretű C/C++ alkalmazások, x64-csak beépülő modulokkal vagy külső DLL-ekkel rendelkező alkalmazások Növekményes migrálás; az emulált részek lassabban futnak, mint a natív
csak x64 (emulált) Olyan alkalmazások, amelyek nem fordíthatók újra, és nem igényelnek csúcsteljesítményt Legegyszerűbb; alacsonyabb akkumulátor-üzemidő és nagyobb késés ARM64-eszközökön

További információkért lásd: Arm64EC – Alkalmazások készítése és portolása natív teljesítményhez Arm rendszeren.

Emuláció (prizma)

Windows 11 ARM-en egy Prism nevű emulációs réteget használ az x64- és x86-alkalmazások ARM64-hardveren való futtatásához. A prism az x86/x64-utasításokat futtatáskor az ARM64-re fordítja le, így széles körű alkalmazáskompatibilitást biztosít anélkül, hogy újrafordítást kellene igényelnie.

  • x64 emuláció – Csak Windows 11 ARM64-eszközökön érhető el (ARM-en nem Windows 10).
  • x86 emuláció – ARM64-eszközökön Windows 10 és Windows 11 is elérhető.
  • Teljesítmény – Az emulált alkalmazások általában elfogadható teljesítménnyel futnak a termelékenységi számítási feladatokhoz, de a grafikus igényű vagy a nagy számítási kapacitású alkalmazások jelentősen kihasználják a natív ARM64- vagy Arm64EC-buildeket.

Jótanács

Ha csak x64-et céloz meg, az alkalmazás továbbra is ARM64-eszközökön fut prism emulációval (csak Windows 11). A natív ARM64-buildek azonban erősen ajánlottak éles alkalmazásokhoz – az emulált alkalmazások több akkumulátort használnak, és nagyobb a késésük. A Copilot+ számítógépeken a natív ARM64 biztosíthatja a legjobb teljesítményt az eszközön futó AI-munkaterhelésekhez.

Store-beküldések esetén töltse fel az architektúraspecifikus csomagokat, vagy egy mindkettőt tartalmazó csomagot. Az Áruház csak a megfelelő architektúrát biztosítja az egyes eszközökhöz.