Windows-alkalmazás fejlesztéssel kapcsolatos gyakori kérdések

Ez a gyakori kérdések Windows alkalmazásfejlesztéssel kapcsolatos gyakori kérdésekre adnak választ, beleértve a projektek megfelelő keretrendszerének kiválasztásával kapcsolatos útmutatást. Az érintett témakörök a következők:

  • Első lépések és az Windows alkalmazásfejlesztési környezet.
  • Natív Windows alkalmazásfejlesztés WinUI 3, Windows megjelenítési alaprendszer (WPF) és Windows Forms (WinForms) használatával.
  • Windows Software Development Kit (SDK) és Windows App SDK.
  • A Windows célzása a platformfüggetlen fejlesztési stratégia részeként.
  • Hibrid és webalkalmazás-fejlesztés .NET MAUI, Blazor és ASP.NET Core használatával.
  • Hogyan válasszunk egy megközelítést, miközben megértjük Microsoft befektetéseit.

Windows alkalmazásfejlesztési környezet

Hol találok egyértelmű áttekintést Windows fejlesztési technológiákról?

A Windows fejlesztők mai lehetőségeinek áttekintéséért tekintse meg a Windows Dev Chat epizódot, amely az ideális fejlesztői platform kiválasztását ismerteti, amely a WinUI 3, a .NET MAUI, a React Native, a Blazor és a Progresszív Web Apps (PWA-k) ismertetését ismerteti. A Windows Dev Chat lejátszási listájában további epizódokat is találhat.

A Windows fejlesztők számára készített alkalmazásfejlesztési lehetőségek áttekintésére is hivatkozhat.

A modern digitális átalakításhoz még mindig elengedhetetlen az ügyfélalkalmazások fejlesztése a cloud services korában?

A felhőszolgáltatások korában az ügyfélalkalmazások fejlesztése továbbra is fontos a felhasználói eszközökön való rugalmas, értelmes interakciók biztosításához.

Íme, miért fontosak az ügyfélalkalmazások:

  • Eszköz elérése: Az ügyfélalkalmazások lehetővé teszik, hogy az alkalmazást közvetlenül a választott eszközökön lévő felhasználókhoz hozza.
  • Átjáró az intelligens szolgáltatásokhoz: ügyfélalkalmazások gyakran az első interakciók a felhasználókkal a szolgáltatásaikkal. Gazdag, interaktív felületet kínálnak, amellyel intelligens funkciókat mutathat be, és megkülönböztetheti a terméket másoktól.
  • Méretezhetőség felhőintegrációval: A jól integrált ügyfélalkalmazás könnyedén szinkronizálható a háttérrendszerbeli felhőszolgáltatásokkal, így a felhasználói bázis növekedésével valós idejű hozzáférést és zökkenőmentes méretezhetőséget tesz lehetővé.
  • Fokozott hatékonyság és felhasználói hűség: Egy átgondolt kialakítású alkalmazás növelheti a termelékenységet, és folyamatosan figyelemmel követheti a felhasználókat a termékével vagy szolgáltatásával.

Natív Windows alkalmazásfejlesztés

Mi a Windows App SDK?

A Windows App SDK független szervizelt összetevőket biztosít Windows asztali alkalmazásokhoz, beleértve a WinUI 3-at, az alkalmazás életciklusát, az ablakozást, az értesítéseket, az erőforrásokat és a szöveges API-kat. Támogatja az Windows 10, 1809-es és újabb verziókon futó alkalmazásokat, a Windows kiadás és Windows App SDK verziójának támogatási életciklusától függően.

Mi a különbség a Windows App SDK és a Windows SDK között?

Mindkettő szoftverfejlesztői készlet (SDK), amely lehetővé teszi Windows alkalmazások készítését.

A(z) Windows App SDK olyan összetevőket biztosít, amelyek a Windowstól függetlenül kerülnek kiadásra, és a támogatott Windows-kiadásokon működnek egészen a Windows 10 1809-es verziójáig. WinUI 3 és API-kat tartalmaz az alkalmazás életciklusához, ablakozásához, értesítéseihez, erőforrásaihoz, szövegéhez és egyéb képességeihez.

A Windows SDK fejléceket, kódtárakat, metaadatokat és eszközöket biztosít az operációsrendszer-API-khoz, például a Win32-hez, a WinRT-hez, a COM-hoz, a DirectX-hez, az eszközökhöz és a rendszerhéjhoz.

A Windows App SDK nem helyettesíti a Windows SDK-t. A Windows App SDK alkalmazó alkalmazások továbbra is használhatják Windows SDK API-kat, és a WinUI 3-alkalmazások gyakran mindkettőt használják.

Új csapatot építek, hogy Windows-only alkalmazást fejlesszünk ki. Miért érdemes natív Windows keretrendszerrel (például WinUI 3, WPF vagy WinForms) fejleszteni?

Az alábbiakban néhány okot talál arra, hogy natív Windows keretrendszert válasszon a Windows-only alkalmazáshoz:

  • Performance: A natív Windows-keretrendszerek a modern Windows hardverek kihasználására vannak optimalizálva, gyors és rugalmas felhasználói élményt biztosítva.
  • Integráció: A Windows olyan API-k széles választékával rendelkezik, amelyek kifinomult élményeket tesznek lehetővé csak Windows alatt. A natív keretrendszerek mély integrációt biztosítanak ezekkel a funkciókkal és API-kkal.
  • Natív felhasználói élmény: A natív keretrendszerek egységes felületet biztosítanak Windows eszközökön, így az alkalmazás mindenhol nagyszerűen néz ki és működik.
  • Offline támogatás: A natív keretrendszerek támogatják az offline forgatókönyveket, így az alkalmazások internetkapcsolat nélkül is működhetnek.
  • Támogatás és eszközhasználat: Microsoft fenntartja a natív keretrendszereket, és aktuális SDK-kat, dokumentációt, hibakeresési eszközöket és mintákat biztosít.
Milyen keretrendszert kell használnom Microsoft legújabb befektetéseivel Windows alkalmazásfejlesztésbe?

Ha új általános célú Windows asztali alkalmazást készít, javasoljuk a WinUI 3 használatát. A WinUI 3 az Windows App SDK által biztosított natív felhasználói felületi keretrendszer. Támogatja Windows asztali alkalmazásokat, és hozzáférést biztosít az aktuális Fluent-vezérlőkhöz és Windows platformképességekhez.

Használhatom a Windows App SDK/WinUI 3-at a meglévő Windows-alkalmazásomban?

Vegye figyelembe, hogy a WinUI 3 (egy felhasználói felületi keretrendszer) a Windows App SDK (Windows platformfejlesztési keretrendszerrel) rendelkezik.

Az alkalmazás felhasználói felületét áttelepítheti a WinUI 3-ba, vagy a WinUI XAML-szigetek használatával Windows App SDK vezérlőket üzemeltethet egy támogatott meglévő asztali gazdagépen. Az örökölt rendszer XAML-szigetei UWP XAML-vezérlőket üzemeltetnek, és különböző API-kat használnak.

A Windows App SDK elemei gyakran használhatók asztali alkalmazásokban a meglévő alkalmazás felépítésétől függően. Az UWP-alkalmazásokat a Windows App SDK nem támogatja.

Ez azt jelenti, hogy WPF/MFC/WinForms-alkalmazások a WinUI 3-hoz nem kapcsolódó Windows App SDK API-kat használhatják. Ilyenek például az alkalmazások életciklusa, az ablakozás és az alkalmazásértesítések.

További információ: Az Windows App SDK használata meglévő projektben.

A WinUI 3-alkalmazások létrehozásához Visual Studio kell használnom?

Nem. A WinUI 3 XAML-buildek az MSBuildet használják, de a .NET SDK-val és az aktuális WinUI 3-sablonokkal egy másik szerkesztő parancssorából készíthet. Lásd a parancssori gyorsútmutatót.

Visual Studio 2026 a leggazdagabb integrált szerkesztési, hibakeresési, profilkészítési és XAML-Hot Reload élményt nyújtja. Használja az eszközhasználati követelményeknek megfelelő munkafolyamatot.

I "Nem tölthető be a DLL "Microsoft.ui.xaml.dll"" hiba az alkalmazás futtatásakor. Hogyan javíthatom ki?

Ez a hiba általában unpackaged olyan alkalmazásforgatókönyvekben fordul elő, ahol a Windows App SDK futtatókörnyezet nincs telepítve a gépen. Kipróbálhatja a következőt:

  • Ha packaged alkalmazást futtat (az ajánlott alapértelmezett), győződjön meg arról, hogy Visual Studio keresztül indítja el a MsixPackage indítási profillal (nem az egyszerű végrehajtható profillal). Az MSIX csomagolási lépés telepíti a szükséges futtatókörnyezeti összetevőket.
  • Ha keretrendszerfüggő csomagolatlan alkalmazást futtat, telepítse a megfelelő Windows App SDK futtatókörnyezetet. Egy önálló üzembe helyezés magában foglalja a Windows App SDK függőségeit.
  • Ellenőrizze, hogy a projekt megfelel-e az üzembehelyezési modellnek. Normál .NET csomagolatlan alkalmazások esetén a beállítás <WindowsPackageType>None</WindowsPackageType> lehetővé teszi Windows App SDK futtatókörnyezet automatikus inicializálását. A bootstrapper API-t csak akkor használja közvetlenül, ha explicit vezérlésre van szüksége a dinamikus függőségek inicializálása felett.

A Windows App SDK-t használó alkalmazások üzembe helyezésével kapcsolatos követelményekről a Windows App SDK alkalmazások üzembe helyezése című részben talál további részleteket.

Mi a különbség a WinUI 3 és a WinUI 2 for UWP között?

A WinUI 3 Microsoft jelenlegi natív felhasználói felületi keretrendszere Windows asztali alkalmazásokhoz, és a Windows App SDK részeként érhető el.

A WinUI 2, más néven WinUI for UWP egy vezérlő- és stíluskódtár az UWP-alkalmazásokhoz. A WinUI 2 és a WinUI 3 különböző XAML-névtereket használ, és nem binárisan kompatibilisek.

Amikor Windows App SDK és WinUI 3 használatával készítek alkalmazást, "WinUI-alkalmazást" építek?

Igen. A WinUI 3 alkalmazás egy olyan alkalmazás legtisztább kifejezése, amelynek felhasználói felülete a WinUI 3-at és a Windows App SDK használja. A WinUI-alkalmazás is gyakran használatos, ha a szövegkörnyezet egyértelmű.

Növekményesen frissíthetem az UWP-alkalmazásomat a WinUI for UWP vezérlőkkel a WinUI 3-ra a vezérlők fokozatos cseréjével?

Nem. Windows App SDK nem használható az UWP-alkalmazásokban, és a WinUI for UWP nem keverhető a WinUI 3-val. Lásd: Migrálás az UWP-ről a Windows App SDK-ra.

Milyen nehéz migrálni egy UWP-alkalmazást a WinUI 3-ba?

Az UWP és a WinUI 3 számos XAML-fogalmat használ, de a migrálás nem közvetlen névtérváltozás. A költség elsősorban a következőtől függ:

  1. Project fájl és MSBuild testreszabás: A migrálási munka a speciális MSBuild használattól függően változik.
  2. .NET API-migrálás: A natív .NET használó UWP-alkalmazások áttérhetnek egy jelenleg támogatott .NET kiadásra a natív AOT használatával. Ez a modernizáció nem a felhasználói felület WinUI 3-ra való migrálása.
  3. Felhasználói felületi összetevők kódtárai: A kódtáraknak a WinUI 3-at célzó verziókkal kell rendelkezniük.
  4. Ablak- és alkalmazásmodell API-k: Az olyan fogalmakhoz kapcsolódó UWP API-k, mint CoreWindowpéldául a , ApplicationViewvagy GetForCurrentView Windows App SDK csere vagy más asztali megközelítés megkövetelése.
  5. C++ nyelvi kivetítés: Ha az UWP-alkalmazás a felülírt C++/CX-előrejelzést használja, portozza a kódot a C++/WinRT fájlba.

További információkért lásd: Migrálás az UWP-ről a Windows App SDK-ra és az UWP és a Windows App SDK API-megfeleltetése.

Ha már van UWP-alkalmazásom az Áruházban, közzétehetek egy új, csomagolt WinUI 3-alkalmazást ugyanazokkal az azonosítókkal?

Igen, a frissített alkalmazások az alkalmazás identitásának frissítése nélkül is közzétehetők. A régi verzió felhasználói az új verzióra frissülnek. Ez csak az asztali alkalmazásokra vonatkozik. Xbox, HoloLens és standard Surface Hub-alkalmazások nem migrálhatók a WinUI 3-ba.

Hogyan csomagolhatom vagy terjeszthetem a WinUI 3-alkalmazásomat?

Lásd: Üzembe helyezés áttekintése.

Hol találhatok Windows App SDK migrálási útmutatót?

Lásd: Migrálás az UWP-ről a Windows App SDK-ra.

Kell-e XAML-jelölőnyelvet használnom, ha a WinUI 3-at szeretném használni?

Nem. A felhasználói felület vezérlői kódban hozhatók létre. Azonban a felhasználói felület deklaratív XAML jelölésének használata számos előnnyel jár, beleértve a továbbfejlesztett fejlesztői élményt is.

  • Migrálás UWP-ről WinUI 3-ra: Számos XAML- és UI-koncepció továbbvihető, de a névterek, a projektmodell és egyes API-k eltérnek.
  • Migrálás a WPF-ről a WinUI 3-ra: Sok fogalom továbbra is alkalmazható, de a vezérlőkészlete és az API-k eltérnek.
Rendelkezik Visual Studio a WinUI 3 tervezési felületével vagy felhasználói felületének tervezőjével?

Jelenleg nem. Az XAML-Hot Reload, az élő vizualizációs fa, az Élő tulajdonságkezelő és a kapcsolódó futtatókörnyezeti eszközök használatával vizsgálja meg és frissítse az XAML-t az alkalmazás futtatása közben.

A WinUI 3-hoz elérhető futtatókörnyezet-tervezési eszközök teljes áttekintéséért tekintse meg a WinUI 3 XAML futtatókörnyezet-tervező eszközeit.

Tartalmazza Windows App SDK a WinUI 3-at?

Igen. A WinUI 3 a Windows App SDK részeként érkezik.

Tartalmazza a Windows App SDK a WinUI-t az UWP-hez?

Nem. A WinUI for UWP az UWP platform része.

A WinUI for UWP és a WinUI 3 ugyanarra a technológiára épül?

Nem egészen. Bár a WinUI 3 a WinUI for UWP kódbázisból indult, ezek különböző technológiák. Mindkettő XAML-alapú felhasználói felületi keretrendszer, amely .NET-tel és C++-szal is működik, de a UWP-hez készült WinUI és a WinUI 3 nem kompatibilis egymással.

Használhatom a WinUI 3-at Windows App SDK használata nélkül?

Nem. A WinUI 3 a Windows App SDK részeként érhető el.

Használhatom a WinUI 3-at csomagolatlan alkalmazásokban?

Igen. A WinUI 3 és számos Windows App SDK API csomagolatlan alkalmazásokban működik. Egyes Windows képességek azonban csomagidentitást igényelnek, és a keretrendszerfüggő csomagolatlan alkalmazásoknak inicializálnia kell a Windows App SDK futtatókörnyezetet. Hasonlítsa össze a Csomagolás áttekintése és a csomagidentitást igénylő funkciók beállítását.

Mi a különbség az XAML-szigetek és a WinUI 3 között?

A WinUI 3 a Windows App SDK részét képező felhasználói felületi keretrendszer. Az XAML-szigetek olyan üzemeltetési technika, amellyel egy meglévő asztali alkalmazás XAML-tartalmat helyezhet el a felhasználói felület mellett egy másik keretrendszerből.

A kifejezés hivatkozhat az UWP XAML-vezérlőket üzemeltető régi rendszer XAML-szigetekre, vagy a támogatott asztali gazdagépeken Windows App SDK vezérlőket üzemeltető WinUI XAML-szigetekre. Az API-k, a névterek és a gazdagép követelményei eltérőek.

Ha létrehozok egy WinUI 3-alkalmazást, modern megjelenésű lesz Windows 11-en és Windows 10-en is?

A WinUI 3 vezérlők a Fluent stílust használják a Windows 10 és a Windows 11 támogatott verzióiban, csomagolt és csomagolatlan alkalmazásokban is. Egyes operációsrendszer-hatások és viselkedések Windows verziótól függően eltérnek. A Mica például a Windows 11-ben érhető el, a Windows 10-ben pedig egyszínű háttérre vált.

Használhatok Mica vagy Acrylic hátteret a Windows App SDK-val készült alkalmazásokban?

Igen. A Desktop Acrylic a Windows 10 1809-es vagy újabb verziójú kiadásaiban támogatott. A Mica használatához Windows 11 szükséges, Windows 10 rendszeren pedig egyszínű témaszínre vált. A háttér alkalmazása előtt futásidőben hívja meg a(z) MicaController.IsSupported vagy DesktopAcrylicController.IsSupported elemet. Lásd A Mica vagy akril anyagok alkalmazása asztali alkalmazásokban Windows 11 esetén.

Hol találom a WinUI 3-mintákat?

Lásd: Minta és erőforrások. Néhány figyelemre méltó adattár:

Ha már jelentős befektetést fektettem be a WPF, akkor továbbra is WPF kell használnom, vagy fontolóra kell venni a WinUI 3-ra való migrálást?

Ha már sokat fektetett be a WPF-be, használhatja továbbra is a meglévő alkalmazásokhoz. WPF egy kiforrott, stabil keretrendszer, amelyet széles körben használnak Windows asztali alkalmazások létrehozásához.

A GitHub Copilot frissítése segítségével felmérheti, majd korszerű .NET-re frissítheti a .NET Framework-alapú WPF-alkalmazást. Tekintse át a létrehozott tervet, és ellenőrizze az alkalmazás minden módosítását.

Ha új WPF-alkalmazást készítek, elavultnak fog tűnni a többi új Windows-alkalmazáshoz képest?

Ha 9-.NET vagy újabb verziójú WPF alkalmazást fejleszt, biztosíthatja, hogy az alkalmazás megfeleljen a Windows 11 elegáns, modern megjelenésének. Az új Fluent téma WPF-hez egy modern Windows 11-es esztétikai stílust vezet be, integrált Világos/Sötét mód és a rendszer kiemelő színének támogatásával. Ez modernizálja az alkalmazás megjelenését, és kifinomult, egységes felhasználói élményt nyújt.

A csapatom kényelmesen készít WinForms-alkalmazásokat, és megfelel az igényeinknek. Érdemes megfontolnunk a WinUI 3-ra vagy más keretrendszerbe való migrálást?

Ha a WinForms megfelel az igényeinek, és csapata jól érzi magát benne, továbbra is használhatja a WinFormst a meglévő alkalmazásokhoz. A WinForms egy kiforrott és stabil keretrendszer, amelyet széles körben használnak Windows asztali fejlesztéshez.

A WinForms csapata továbbra is befektet a platformba. A legutóbbi és a folyamatban lévő munka a következőket foglalja magában:

  • Aszinkron űrlap és párbeszédpanel API-k
  • Sötét mód és vizuális stílus támogatása
  • Akadálymentességi, nagy DPI-s, elrendezési és tervezői fejlesztések
  • A vágólap és a DataObject korszerűsítése

Platformfüggetlen natív fejlesztés

Mi lehet az oka a platformfüggetlen, natív alkalmazások létrehozásának, amelyek Windows célként szerepelnek?

Ha több operációsrendszer-platformon célozza meg a felhasználókat, a platformfüggetlen alkalmazások .NET MAUI vagy React Natív használatával történő létrehozása számos előnyt kínálhat:

  • Elér: A platformfüggetlen alkalmazások nagyobb közönséget érnek el különböző eszközökön és operációs rendszereken.
  • Kód újrafelhasználása: A kód platformok közötti újrafelhasználása csökkenti a fejlesztési időt és a költségeket. Az Windows, Android, iOS és macOS rendszerekhez készült különálló alkalmazások létrehozása rendkívül költséges lehet.
  • Konzisztens felhasználói élmény: A platformfüggetlen keretrendszerek egységes megjelenést és érzetet biztosítanak a különböző platformokon.
  • Integráció: A platformfüggetlen alkalmazások továbbra is integrálhatók a platformspecifikus szolgáltatásokkal, hogy átfogó élményt nyújtsanak.
Meg vagyok győződve arról, hogy .NET MAUI alkalmazások jól fognak futni Windows?

Amikor Windows .NET MAUI alkalmazást hoz létre, a kimenet WinUI 3-at használ. A fejlesztés során a .NET MAUI egyetlen .NET felületet kínál a platformokon, de platformspecifikus kódot hoz létre a motorháztető alatt.

Hogyan .NET MAUI biztosíthat natív eszköz API-kat minden platformon?

.NET MAUI egységes .NET élményt nyújt Windows, iOS, Android és macOS rendszereken. Platformfüggetlen API-kat kínál olyan gyakori képességekhez, mint a tárolás, a hálózatkezelés és az eszközérzékelők. Platformspecifikus API-kat is hívhat, vagy speciális implementációkat biztosíthat az egyes platformokhoz.

Kezdhetem a WinUI 3-mal, és később integrálhatom a .NET MAUI-t, ha idővel többplatformos forgatókönyveket is szeretnék megcélozni?

Jelenleg nem. Bár .NET MAUI WinUI 3-at használ Windows futtatásakor, a több platformot célzó csapatoknak .NET MAUI vagy a React Native for Desktop használatával kell kezdődnie.

Csapatunk erős webes előtérbeli fejlesztési készségekkel rendelkezik. Érdemes megfontolnunk a React Native for Desktop használatát?

Az erős webes fejlesztési tapasztalattal rendelkező csapatok érdemes lehet figyelembe venni a React Native for Desktopot. Tartalmazza a React Native-t Windows és macOS rendszerekhez. A "Learn once, write anywhere" (Tanulás egyszer, bárhol írás) megközelítéssel a meglévő JavaScript-, TypeScript- és React-képességek natív Windows és macOS-alkalmazások készítésére használhatók.

A React Native for Desktop közvetlenül natív primitívek számára rendereli a felhasználói felületet, így natív teljesítményt és platformképességeket biztosít.

A kezdéshez lásd a React Native for Desktop dokumentációját.

Támogatja-e a React Native for Desktop más Windows eszközöket?

A React Native for Windows támogatja a kompatibilitási dokumentációjában felsorolt Windows verziókat. Ellenőrizze, hogy az eszközcsalád támogatja-e a React natív verzióját a megcélzott Windows verzióhoz, és ne feltételezze, hogy minden Windows eszköz támogatott.

Mit használjak, ha olyan alkalmazásokat szeretnék készíteni, amelyek működnek Windows és Xbox rendszeren?

Xbox-alkalmazásokhoz használja az UWP-t, és vegye figyelembe a Xbox-specifikus UWP-korlátozásokat. A játékfejlesztéshez használja a Microsoft Játékfejlesztő készlet.

Ha Windows és Surface Hubon működő alkalmazásokat szeretnék létrehozni?

A standard Teams-szobákat vagy Surface Hub-környezetet futtató Surface Hubhoz használjon olyan UWP-alkalmazást, amely megfelel a Surface Hub alkalmazás követelményeinek. A Windows 11 Pro vagy Enterprise használatával konfigurált Surface Hub 3 támogatott asztali alkalmazástechnológiákat futtathat, így nem az UWP az egyetlen lehetőség ebben a konfigurációban.

Hibrid és webes fejlesztés

Mik azok a hibrid alkalmazások, és miért érdemes megfontolni a létrehozásukat?

A hibrid alkalmazások a legjobb webes és natív alkalmazásfejlesztést ötvözik. Alapjuk olyan webes technológiákkal épül fel, mint a HTML, a CSS és a JavaScript, és egy natív tárolóba vannak csomagolva, amely access bizonyos natív platformfunkciókhoz és hardverekhez. Alkalmazás-áruházakon keresztül is terjeszthetők.

A fő előnye, hogy a hibrid alkalmazások lehetővé teszik egyetlen alkalmazás összeállítását, amely több natív platformon és a weben is futtatható, csökkentve a fejlesztési időt és a költségeket. A hibrid alkalmazásfejlesztési platformok például a következők:

  • Elektron asztali alkalmazásokhoz
  • Ionic mobilalkalmazásokhoz
  • .NET MAUI Blazor Hybrid platformfüggetlen alkalmazásokhoz
Hogyan építek natív érzetű progresszív webalkalmazásokat Windows?

Lásd: Webfejlesztés Windows rendszeren és Progresszív webalkalmazások áttekintése.

Mi az .NET MAUI Blazor hibrid alkalmazás?

A .NET MAUI a Blazor-alkalmazások natív módon futtathatók Windows, iOS, Android és macOS rendszeren. Ez lehetővé teszi olyan hibrid ügyfélalkalmazások létrehozását, amelyek egyetlen natív ügyfélalkalmazásban egyesítik a Blazort és .NET MAUI összetevőket, teljes hozzáféréssel a natív platform képességeihez.

További információ: ASP.NET Core Blazor Hybrid.

Az .NET MAUI hibrid alkalmazás webes összetevőit a Blazor használatával kell létrehozni

Nem. A .NET 9-től kezdve a .NET MAUI tartalmaz egy HybridWebView vezérlőt, amely lehetővé teszi más JavaScript-alapú felhasználói felületek natív alkalmazásokon belüli üzemeltetését.

Ez lehetővé teszi az Angular, React, Vue vagy más HTML/JavaScript-alkalmazások üzemeltetését egy .NET MAUI alkalmazásban. A hibrid vezérlő kapcsolatot biztosít a C# és a JavaScript között, így a C#-kód meghívhatja a JavaScript-függvényeket, és fordítva.

Bármely más natív alkalmazástípus üzemeltethet hibrid Blazor-összetevőket?

Igen. WPF és WinForms-alkalmazások a Blazor hibrid összetevőit is üzemeltethetik, lehetővé téve a modern webes felhasználói felület hozzáadását a meglévő alkalmazásokhoz. Ez nem támogatott WPF vagy .NET-keretrendszerre épülő WinForms-alkalmazások esetében.

A teljes alkalmazásomnak hibrid alkalmazásnak kell lennie, vagy kombinálhatom és egyeztethetem a natív és hibrid összetevőket?

A natív és a hibrid összetevők keverhetők egy alkalmazáson belül. Előfordulhat például, hogy egy alkalmazás magja .NET MAUI összetevőkkel épül fel, míg a hibrid összetevők további funkciókat biztosítanak. Ez lehetővé teszi a natív összetevők teljesítményének és képességeinek kombinálását a hibrid összetevők rugalmasságával és költséghatékonyságával.

Mi a választásom .NET-alapú webalkalmazások létrehozására, amelyek nagyszerűen mutatnak a modern böngészőkben a Windows?

Web apps bármely ügyfélalkalmazás-platform legszélesebb körét kínálja. A gyönyörű .NET webalkalmazások létrehozásának lehetőségei a következők:

  • ASP.NET Core-alkalmazások a Razor Pages használatával
  • ASP.NET Core MVC-alkalmazások
  • ASP.NET Core Blazor-alkalmazások üzemeltetési modellbeállításokkal:
    • Blazor WebAssembly (egy .NET alapú keretrendszer, amely lehetővé teszi webes alkalmazások futtatását közvetlenül a böngészőben)
    • Blazor Server

A Blazor üzemeltetési modelljei most már konfigurálhatók az összetevők szintjén, így olyan forgatókönyvek is engedélyezhetők, mint a Blazor WebAssembly-összetevők üzemeltetése a Blazor Server-alkalmazásokban.

További részletekért tekintse meg a ASP.NET Core dokumentációját.

Válasszon egy megközelítést, és ismerje meg Microsoft befektetéseit

A Windows megcélzott alkalmazások létrehozásához rengeteg keretrendszer-lehetőség áll rendelkezésre. Hogyan dönthetek?

Windows egy nyílt platform, amely számos technológiát támogat. Íme néhány feltétel, amely segíthet a platform kiválasztásában:

  • Windows-fókuszú vagy platformfüggetlen fejlesztést végez?
  • Milyen nyelvekkel vagy készségekkel rendelkezik már – .NET, JavaScript, valami más?
  • Hozzáférésre van szüksége Windows-specifikus API-khoz?
  • Melyik keretrendszer képességei felelnek meg a legjobban az alkalmazás követelményeinek?
  • További összehasonlító tényezőkért tekintse meg ezt a táblázatot .

Számos üzleti alkalmazás esetében a csapatok gyakran a meglévő készségek és a csapat által a legkényelmesebb használat alapján választanak.

Hogyan választhatom ki a webalkalmazásom legjobb fejlesztési megközelítését?

A webalkalmazás fejlesztési megközelítésének kiválasztásakor vegye figyelembe az alábbiakat:

  • Blazor ajánlott a frontend webalkalmazások fejlesztéséhez .NET-tel. Lehetővé teszi az előtérbeli és a háttérrendszer .NET használatával történő összeállítását, időt és költséget takarítva meg, és különösen jó a nagyvállalati alkalmazások számára.
  • A JavaScript web apps akkor is van értelme, ha meglévő JavaScript-készségeket szeretne használni, vagy integrálnia kell a meglévő JS-kódtárakkal vagy -keretrendszerekkel.
  • A régebbi keretrendszereket, például a Web Formst, az MVC-t vagy a Razor Pagest használó meglévő alkalmazások továbbra is támogatottak, és továbbra is fejleszthetők és karbantarthatók.
Ki készít alkalmazásokat a WinUI 3 használatával?

Microsoft Fényképek egy dokumentált példa. Az alkalmazás az UWP-ről a Windows App SDK migrált, és továbbra is a WinUI 3-at használja. Az architektúrával és a migrálással kapcsolatos részletekért lásd: Microsoft Fotók: Migrálás UWP-ről Windows App SDK.

Ki készíti ma a .NET MAUI alkalmazásokat?

A szervezetek .NET MAUI használnak platformfüggetlen alkalmazások létrehozására Androidhoz, iOS-hez, macOS-hez és Windows. Példák az .NET ügyfélbemutatóban.

Ki fejleszt ma WPF alkalmazásokat?

A Microsoft Visual Studio felhasználói felületének többsége WPF van kialakítva. Maga a Visual Studio IDE egy összetett, nagy teljesítményű WPF alkalmazás egyik fő példája.

Ki készít ma Blazor-alkalmazásokat?

A GE Digital FlightPulse légitársasági rendszere a Blazort használja a pilóták által látottak háttérkonfigurációjához, így az érzékelőadatok és az elemzések közvetlenül a pilótákhoz való eljuttatásával javítják a biztonságot és a hatékonyságot.

További Blazor-ügyféltörténetek a .NET webhelyen.

Nyelvválasztás (.NET és C++)

C# vagy C++ elemet kell használnom a Windows alkalmazásomhoz?

A legtöbb esetben használja a C# (.NET) parancsot. A C# gyorsabb fejlesztést, memóriabiztonságot, gazdag kódtárakat és kiváló eszközhasználatot biztosít. A legtöbb Windows alkalmazás – beleértve a WinUI 3, a WPF, a WinForms és a .NET MAUI alkalmazásokat – a legjobban a C# használatával készült.

A C++- ot akkor használja, ha közvetlen hardverhozzáférésre, minimális futásidejű többletterhelésre vagy meglévő C++ kódbázisokkal való együttműködésre van szüksége. A C++ forgatókönyvek közé tartoznak a játékmotorok (DirectX), az illesztőprogramok, a rendszerszintű segédprogramok és a teljesítmény szempontjából kritikus összetevők.

Tényező C# (.NET) C++
Fejlesztési sebesség ✅ Gyorsabb – felügyelt memória, gazdag ökoszisztéma ⚠️ Lassabb – manuális erőforrás-kezelés
Futásidejű teljesítmény ✅Kiváló a modern .NET-tel (AOT, Span<T>) ✅ A lehető legjobb — nincsenek szemétgyűjtési szünetek
Memóriabiztonság ✅ Szemétgyűjtés ⚠️ Kézikönyv – szivárgások és biztonsági rések kockázata
WINDOWS API-hozzáférés ✅ C#/WinRT-vetítéssel ✅ C++/WinRT-vetítéssel
WinUI 3-támogatás ✅ Teljes körű támogatás ✅ Teljes támogatás a C++/WinRT használatával
Platformfüggetlen ✅.NET Windows, Linux, macOS rendszeren fut ✅ Platformspecifikus kóddal
Legjobb a számára Üzleti alkalmazások, CRUD, szolgáltatások, felhasználói felületi alkalmazások Játékok, illesztőprogramok, rendszereszközök, alacsony késés

Mindkettőt kombinálhatja: létrehozhatja az alkalmazást C# nyelven, és meghívhatja a teljesítmény szempontjából kritikus natív kódot a P/Invoke (CsWin32) vagy egy C++/WinRT-összetevő használatával.

Hogyan hívhatom meg a Win32 API-kat a C#-ból?

Használja a CsWin32 forrásgenerátort, amely típusbiztos P/Invoke aláírásokat hoz létre a létrehozáskor. Hozzáadhatja a Microsoft.Windows.CsWin32 NuGet-csomagot, listázhatja a fájlban NativeMethods.txt szükséges API-kat, és meghívhatja őket egy létrehozott PInvoke osztályon keresztül.

A CsWin32 bármilyen C#-projektben lecseréli a kézzel írt [DllImport] deklarációkat, és működik, beleértve a WinUI 3, a WPF, a WinForms és a konzolalkalmazásokat. Részletes útmutatóért tekintse meg a Win32 API-k meghívását egy C# Windows-alkalmazásból (CsWin32).

Mi az a C++/WinRT, és mikor érdemes használni?

A C++/WinRT egy standard C++17 nyelvi kivetítés Windows-futtatókörnyezet API-khoz. Használja Windows WinRT API-kat használó vagy létrehozó C++-alkalmazások létrehozásakor. A C++/CX és a Windows-futtatókörnyezet C++ sablontár (WRL) helyébe lép.

A következő esetekben válassza a C++/WinRT lehetőséget:

  • Ön egy C++-os WinUI 3-alkalmazást készít
  • Más nyelvek által használt Windows-futtatókörnyezet összetevőket kell létrehoznia
  • Áttelepítés C++/CX környezetből
Mi az a C#/WinRT, és mikor van rá szükségem?

A C#/WinRT winRT-vetítési támogatást nyújt a C# számára. A legtöbb esetben nem kommunikál vele közvetlenül – .NET Windows célalkalmazások automatikusan hozzáférést kapnak a WinRT API-khoz a cél keretrendszerbeli monikereken (TFM-ek) keresztül. A C#/WinRT-re kifejezetten szükség van, ha C#-ban írt Windows-futtatókörnyezet-összetevőket hoz létre, vagy ha külső féltől származó WinRT-összetevőkhöz generál interop szerelvényeket.

Csomagolás, üzembe helyezés és frissítések

Mi a különbség a külső helyen csomagolt, csomagolatlan és csomagolt alkalmazások között?

A csomagolt alkalmazások fájlokat, identitásokat és üzembehelyezési információkat tartalmaznak egy csomagban, például az MSIX-ben. A csomagolatlan alkalmazások a Windows csomagrendszeren kívüli telepítőt vagy üzembe helyezési folyamatot használnak, és alapértelmezés szerint nem rendelkeznek csomagadentitással. A külső helyre csomagolt alkalmazás kis identitáscsomagot használ, miközben megtartja a külső helyen található binárisokat, valamint a meglévő telepítőjét és frissítési folyamatát.

A követelményekről és a kompromisszumokről lásd a Csomagolás áttekintését .

Szükségem van csomagidentitásra?

Ez az alkalmazás által használt Windows funkcióktól függ. A csomagidentitás olyan forgatókönyvekhez szükséges, mint a csomagolt háttérfeladatok, a megosztási célok, az indítási feladatok, az egyéni helyi menücsomag-bővítmények, a jegyzékalapú fájltípus- és protokolltársítások, valamint számos Windows AI API. A Windows App SDK identitás nélkül is támogatja a push értesítések korlátozott előtérbeli forgatókönyveit, de a háttérbeli kézbesítéshez és a COM-aktiváláshoz identitás szükséges. A WinUI 3 és a helyi alkalmazásértesítések csomagadentitás nélkül is működhetnek.

Lásd a csomagazonosságot igénylő jellemzők. Ha identitásra van szüksége, de meg kell őriznie egy meglévő telepítőt, fontolja meg a külső helyen való csomagolást.

Mi a különbség a keretrendszerfüggő és az önálló üzembe helyezés között?

A keretrendszerfüggő alkalmazások az eszközön külön telepített Windows App SDK futtatókörnyezeti csomagokat használnak. Ez csökkenti az alkalmazás üzembe helyezésének méretét, és lehetővé teszi a telepített keretrendszer számára a karbantartási frissítések fogadását. Egy önálló alkalmazás magában hordozza a Windows App SDK függőségeit, ami növeli az üzembe helyezés méretét, és az alkalmazás közzétevője felelőssé teszi a frissítések Windows App SDK új alkalmazásverziókkal való terjesztéséért.

A további MSIX-csomagoktól, például a Singleton-csomagtól függő API-k külön üzembe helyezési vagy futtatókörnyezeti támogatási ellenőrzéseket igényelhetnek még önálló alkalmazásokban is. A csomagolás és a futtatókörnyezet telepítése külön döntések. Lásd Windows App SDK üzembe helyezésének áttekintését.

A WinUI 3 alkalmazás automatikusan frissül a végfelhasználók számára?

Egy WinUI 3-alkalmazás terjeszthető a Microsoft Store-on keresztül, egy .appinstaller fájlban, illetve MSI-csomag vagy telepítőprogram formájában. Az áruházcsomagok frissíthetők Microsoft Store karbantartással, az Áruház és a szervezeti beállítások függvényében. Az .appinstaller üzembe helyezés csak akkor támogatja az automatikus frissítéseket, ha a UpdateSettings indításkori vagy háttérbeli ellenőrzéseket konfigurálnak. Az MSI-nek és a telepítési környezeteknek saját frissítési mechanizmust kell biztosítaniuk vagy integrálniuk.

Használhatom a Windows App SDK-t MSBuild használata nélkül?

Igen, bizonyos helyzetekben. A WinUI 3 XAML-projektekhez jelenleg msBuild szükséges, bár Visual Studio nincs szükség, és dotnet build meghívhatja az MSBuild parancsot a parancssorból. A C++ és CMake-projektek nem XAML-Windows App SDK API-jait az előzetes verziójú Windows-alkalmazás fejlesztői parancssori felületen használhatja, vagy manuálisan integrálhatja a futtatókörnyezetet.

Windows AI (mesterséges intelligencia)

Hogyan választhatok Windows AI API-k, Foundry Local és Windows ML között?

Az első három technológia a Windows rendszerhez készült Microsoft Foundry része. Ezeket kombinálhatja egymással és a felhőmodellekkel ugyanabban az alkalmazásban:

  • A Windows AI API-kat olyan használatra kész képességekhez használhatja, amelyek modelljeit és hardveres gyorsítását Windows kezeli.
  • A Foundry Local használatával helyileg felderítheti, letöltheti és futtathatja a támogatott nyílt forráskódú nyelvi és beszédmodelleket.
  • A Windows ML használatával saját ONNX-modelleket futtathat végrehajtási szolgáltatókkal az elérhető CPU-, GPU- és NPU-hardverekhez.
  • Ha felhőalapú modellekre, lekéréses, központosított irányításra vagy a céleszközön nem elérhető képességekre van szüksége, használja a Microsoft Foundryt, amely egy külön felhőbeli AI-platform.

Hasonlítsa össze a Windows AI-megoldás kiválasztásával elérhető lehetőségeket. Fontolja meg a modellképességet, az adatvédelmet, a kapcsolatot, a késést, a hardveres lefedettséget, az üzembe helyezés méretét és az üzemeltetési költségeket.

A Windows AI-funkciókhoz szükséges-e Copilot+ PC?

Nem mindegyiket. Sok Windows AI API-hoz Copilot+ PC van szükség, de egyes API-k bizonyos GPU-kat vagy processzorokat is támogatnak. A Foundry Local és a Windows ML szélesebb körű hardverkonfigurációkat támogat, az operációs rendszer, a modell, a futtatókörnyezet és a végrehajtási szolgáltató aktuális követelményeitől függően.

Ellenőrizze az Windows AI API hardvertáblát, valamint az adott API vagy modell követelményeit. Észlelje futásidőben a támogatást és a modell készenlétét, és biztosítson nem AI-alapú, helyi modellre épülő vagy felhőalapú tartalék megoldást, ha a funkció nem érhető el.

Futtathatók helyileg és offline Windows AI-funkciók?

Igen. Windows AI API-k, a Foundry Local és a Windows ML következtetést futtathat a felhasználó eszközén, ami csökkentheti a késést, és helyien tarthatja a bemeneti adatokat. Egyes modelleket vagy végrehajtási szolgáltatókat először le kell tölteni vagy ki kell telepíteni, és internetkapcsolatra lehet szükség a beállítás vagy a karbantartás során. A felhőalapú AI-szolgáltatásoknak kapcsolatra van szükségük, és az adatkezelési feltételeknek megfelelően adatokat kell küldeni a szolgáltatásnak.

Tájékoztassa a felhasználókat arról, hogy mikor van szükség modellletöltésre, és mikor hagyják el az adatokat az eszközről. Ne írjon le egy funkciót offline módúként, amíg nem tesztelte a teljes első futtatási, frissítési és tartalékélményt.

Segíthetnek az AI-eszközök egy Windows-alkalmazás létrehozásában vagy modernizálásában?

Igen. Az AI-kódolási ügynökök segíthetnek a projektek összeállításában, az API-k magyarázatában, a kód áttelepítésében, a tesztek létrehozásában és a buildelési problémák diagnosztizálásában. Használja az AI által támogatott Windows fejlesztési útmutatót a GitHub Copilot, a WinUI-ügynök beépülő modulhoz, a Microsoft Learn MCP-kiszolgálóhoz, a migrálási munkafolyamatokhoz és az AI által támogatott teszteléshez.

Tekintse át és tesztelje a létrehozott kódot, ahogyan bármilyen más közreműködést. Különösen ellenőrizze az API-neveket és -verziókat, a csomagképességeket, a biztonsági szempontból érzékeny kódot, az akadálymentességet és az UWP-to-WinUI 3-as helyettesítéseket.

Mit érdemes figyelembe vennem egy MI-vel támogatott funkció bevezetése előtt?

Határozza meg a szolgáltatás tervezett használatát és korlátozásait, értékelje a minőséget és a biztonságot reprezentatív adatokkal, szükség esetén tegye közzé az AI viselkedését, védje a felhasználói adatokat, és tartalékot biztosítson, ha a modell vagy a szükséges hardver nem érhető el. A titkos információkat és az emelt jogosultságú szolgáltatás-hitelesítő adatokat ne tárolják az ügyfélalkalmazásokban, és követeljék meg a felhasználói megerősítést a jelentős következményekkel járó vagy visszafordíthatatlan műveletek előtt. Lásd: Felelős generatív AI-fejlesztés a Windows és a biztonság területén, valamint a felelős mesterséges intelligencia Windows fejlesztéshez.

Teljesítmény és optimalizálás

Mi a teendő, hogy a Windows-alkalmazásom jól érezze magát a végfelhasználók számára?

Tekintse meg Windows alkalmazásfejlesztés – Ajánlott eljárások és Windows alkalmazások teljesítményével és alapjaival kapcsolatos áttekintést.

Compatibility

A felhasználóimnak frissíteniük kell majd Windows a WinUI 3-alkalmazásom használatához?

A Windows App SDK által támogatott minimális kompatibilis operációs rendszer a Windows 10, 1809-es verzió, 17763-as build. Microsoft támogatáshoz támogatott Windows App SDK kiadásra van szükség a legújabb karbantartási frissítéssel, valamint egy Windows kiadással, verzióval és karbantartási csatornával, amely továbbra is támogatott. Az egyes API-k újabb Windows verziót vagy adott hardvert igényelhetnek. Lásd Windows App SDK támogatási és kiadási csatornákat.

Megcélzhatom az Arm64-et a WinUI 3-alkalmazásommal?

Igen. Natív Arm64-alkalmazás létrehozása a legjobb teljesítmény és hatékonyság érdekében. Az x64-függőségekkel rendelkező nagy C++ kódbázis esetén az Arm64EC lehetővé teszi a modulok növekményes migrálását. Windows 11 az Armen számos meglévő x86- és x64-alkalmazást is futtathat a Prizma emuláción keresztül, de tesztelnie kell a teljesítményt és a kompatibilitást a reprezentatív Arm-eszközökön.

Elavulások és migrálások

Elavult az UWP/WinUI az UWP-hez?

Az UWP és a WinUI 2 formálisan nem elavult. Visual Studio 2026 támogatja az UWP-t modern .NET és natív AOT használatával, míg a WinUI 2.8 továbbra is az UWP legújabb stabil WinUI-kiadása. A Microsoft azonban a WinUI 3-at és a Windows App SDK javasolja az új általános célú Windows asztali alkalmazásokhoz.

Általánosan elérhető a Natív AOT-alapú modern .NET UWP-támogatása, amely a 2026-os Visual Studio alapértelmezett C# UWP-projekttípusa. Egy meglévő UWP-alkalmazás áthelyezése .NET natívról modern .NET egy külön modernizációs lépés a felhasználói felület WinUI 3-ra való migrálásától. Lásd: UWP-alkalmazás modernizálása .NET és natív AOT használatával.

Mikor kell migrálnom egy UWP/WinUI for UWP alkalmazást a WinUI 3-ba?

Az UWP-fejlesztők nem érezhetik a migrálásra nehezedő nyomást, ha elégedettek az UWP-vel és annak funkciókészletével – sok alkalmazás esetében a megfelelő választás lehet az UWP használata.

Azokat az alkalmazásokat, amelyek a legújabb Windows platform és .NET beruházások előnyeit szeretnék kihasználni, érdemes lehet áttérni a WinUI 3-ra és a Windows App SDK. Lásd: Migrálás az UWP-ről a Windows App SDK-ra.

Mikor *ne* migráljak egy UWP + WinUI for UWP alkalmazást WinUI 3-ra?

Folytassa az UWP használatát, ha a céleszköz vagy alkalmazásmodell megköveteli azt, például Xbox alkalmazásokat, HoloLens 2D-s alkalmazásokat vagy a szabványos Surface Hub-környezethez tartozó alkalmazásokat. Windows IoT Enterprise támogatja az asztali alkalmazástechnológiát, beleértve a Windows App SDK, így az IoT-cél önmagában nem ok az UWP használatára.

Már nem támogatott a WPF?

Nem. WPF támogatott, és továbbra is funkció-, teljesítmény-, akadálymentességi és Fluent-stílusú fejlesztéseket kap a modern .NET. Továbbra is jó választás a meglévő WPF alkalmazások és az új alkalmazások számára, amelyek követelményei megfelelnek WPF. Az új általános célú Windows asztali alkalmazások esetében Microsoft elsődleges ajánlása a WinUI 3 és a Windows App SDK. Tekintse meg a WPF ütemtervet GitHub.

Használaton kívüli a WinForms?

Nem. A WinForms támogatott, és továbbra is megkapja a funkciófrissítéseket. Lásd a Windows Forms ütemtervet a GitHubon.

A Windows-futtatókörnyezet (WinRT) elavult?

Nem. A WinRT egy alkalmazás bináris felülete (ABI), amely lehetővé teszi a több nyelv közötti interopációt. A WinRT a COM fejlődése, és a Windows App SDK a legtöbb funkcióját a WinRT API-kon keresztül biztosítja.

Kibocsátási megjegyzések

Hol találom a Windows App SDK kiadási megjegyzéseit?

Lásd a Windows App SDK kiadási megjegyzéseit a stabil, előzetes és kísérleti kiadásokhoz. A Windows fejlesztőknek szóló újdonságok oldal összefoglalja a legújabb Windows SDK-t, Windows App SDK, WinUI 3-at, eszköz- és platformfrissítéseket.

Kapcsolódó tartalom

  • Last updated on