Vanliga frågor och svar om Windows App utveckling

Vanliga frågor och svar innehåller svar på vanliga frågor om Windows programutveckling, inklusive vägledning om hur du väljer rätt ramverk för dina projekt. Ämnen som tas upp är:

  • Komma igång och Windows apputvecklingslandskapet.
  • Inbyggd apputveckling med endast Windows med WinUI 3, Windows Presentation Foundation (WPF) och Windows Forms (WinForms).
  • Windows Software Development Kit (SDK) och Windows App SDK.
  • Rikta in dig på Windows som en del av din plattformsoberoende utvecklingsstrategi.
  • Hybrid- och webbappsutveckling med .NET MAUI, Blazor och ASP.NET Core.
  • Så här väljer du en metod samtidigt som du förstår Microsoft investeringar.

Windows apputvecklingslandskap

Var kan jag hitta en enkel översikt över Windows-utvecklingsteknologier?

En översikt över dagens alternativ för Windows utvecklare finns i avsnittet Windows Dev Chat Om du väljer din perfekta utvecklingsplattform, som diskuterar WinUI 3, .NET MAUI, React Native, Blazor och Progressive Web Apps (PWA). Du hittar andra avsnitt i spellistan Windows Dev Chat.

Du kan också referera till översikt över apputvecklingsalternativ för Windows utvecklare.

Varför är klientappsutveckling fortfarande avgörande för modern digital omvandling i molntjänsternas era?

I molntjänsternas tidsålder är utveckling av klientappar fortfarande viktigt för att leverera dynamiska och meningsfulla interaktioner på användarenheter.

Det här är anledningen till att klientappar spelar roll:

  • Enhetens räckvidd: Med klientappar kan du ta ditt program direkt till användarna på valfria enheter.
  • Gateway to Intelligent Services: Klientappar är ofta den första interaktionen som användarna har med dina tjänster. De erbjuder ett omfattande, interaktivt gränssnitt som gör att du kan visa upp intelligenta funktioner och skilja din produkt från andra.
  • Scalability with Cloud Integration: En välintegrerad klientapp kan enkelt synkroniseras med serverdelen cloud services, vilket möjliggör realtidsdata access och sömlös skalbarhet allt eftersom användarbasen växer.
  • Förbättrad produktivitet och användarlojalitet: En genomtänkt app kan förbättra produktiviteten och hålla användarna delaktiga i din produkt eller tjänst över tid.

Inbyggd apputveckling med endast Windows

Vad är Windows App SDK?

Windows App SDK tillhandahåller oberoende servicekomponenter för Windows skrivbordsappar, inklusive WinUI 3, applivscykel, fönster, meddelanden, resurser och text-API:er. Den stöder appar som körs på Windows 10, version 1809 och senare, beroende på supportlivscykeln för Windows-versionen och versionen av Windows App SDK.

Vad är skillnaden mellan Windows App SDK och Windows SDK?

Båda är programutvecklingspaket (SDK:er) som gör att du kan skapa Windows appar.

Windows App SDK tillhandahåller komponenter som levereras oberoende av Windows och fungerar i Windows versioner som stöds ned till Windows 10 version 1809. Den innehåller WinUI 3 och API:er för applivscykel, fönster, meddelanden, resurser, text och andra funktioner.

Windows SDK innehåller rubriker, bibliotek, metadata och verktyg för operativsystem-API:er som Win32, WinRT, COM, DirectX, enheter och gränssnittsfunktioner.

Windows App SDK ersätter inte Windows SDK. Appar som använder Windows App SDK kan fortsätta att använda Windows SDK-API:er och WinUI 3-appar använder ofta båda.

Jag bygger ett nytt team för att utveckla en Windows-only-app. Varför ska jag välja att utveckla med ett internt Windows ramverk som WinUI 3, WPF eller WinForms?

Här följer några anledningar till att välja ett internt Windows ramverk för din Windows-only-app:

  • Performance: Interna Windows ramverk är optimerade för att utnyttja modern Windows maskinvara, vilket ger snabba och dynamiska användarupplevelser.
  • Integration: Windows levereras med en mängd olika API:er som möjliggör avancerade upplevelser som endast är tillgängliga på Windows. Interna ramverk ger djup integrering med dessa funktioner och API:er.
  • Native user experience: Native frameworks ger en konsekvent upplevelse på Windows enheter, vilket säkerställer att appen ser ut och fungerar bra överallt.
  • Offlinestöd: Interna ramverk stöder offlinescenarier, vilket gör att appar kan fungera även utan internetanslutning.
  • Stöd och verktyg: Microsoft underhåller de interna ramverken och tillhandahåller aktuella SDK:er, dokumentation, felsökningsverktyg och exempel.
Vilket ramverk ska jag använda för att utnyttja Microsoft senaste investeringar i Windows apputveckling?

Om du skapar en ny Windows skrivbordsapp för generell användning rekommenderar vi att du använder WinUI 3. WinUI 3 är det interna användargränssnittsramverket som levereras med Windows App SDK. Den stöder Windows skrivbordsappar och ger åtkomst till aktuella Fluent-kontroller och Windows plattformsfunktioner.

Kan jag använda Windows App SDK/WinUI 3 i min befintliga Windows app?

Observera att WinUI 3 (ett UI-ramverk) levereras med Windows App SDK (ett Windows plattformsutvecklingsramverk).

Du kan migrera appens användargränssnitt till WinUI 3 eller använda WinUI XAML Islands som värd för Windows App SDK kontroller i en befintlig skrivbordsvärd som stöds. Äldre system XAML Islands är värd för UWP XAML-kontroller och använder olika API:er.

Element i Windows App SDK kan ofta användas i skrivbordsappar, beroende på hur den befintliga appen skapades. UWP-appar stöds inte av Windows App SDK.

Det innebär att WPF/MFC/WinForms-appar kan använda Windows App SDK API:er som inte är relaterade till WinUI 3. Exempel är applivscykel, fönster och appaviseringar.

Mer information finns i Använd Windows App SDK i ett befintligt projekt.

Behöver jag använda Visual Studio för att skapa WinUI 3-appar?

Nej. WinUI 3 XAML-versioner använder MSBuild, men du kan skapa med .NET SDK och aktuella WinUI 3-mallar från kommandoraden i en annan redigerare. Se snabbstarten för kommandoraden.

Visual Studio 2026 har den rikaste integrerade upplevelsen för redigering, felsökning, profilering och XAML-Hot Reload. Använd arbetsflödet som matchar dina verktygskrav.

Jag får ett felmeddelande "Kan inte läsa in DLL 'Microsoft.ui.xaml.dll'" när jag kör min app. Hur åtgärdar jag det?

Det här felet uppstår vanligtvis i unpackaged appscenarier där Windows App SDK-körningen inte har installerats på datorn. Prova följande:

  • Om du kör en packaged app (rekommenderad standard) bör du starta via Visual Studio med MsixPackage startprofil vald (inte den oformaterade körbara profilen). MSIX-paketeringssteget installerar de nödvändiga körningskomponenterna.
  • Om du kör en ramverksberoende opaketerad app installerar du den motsvarande Windows App SDK-runtime. En fristående distribution innehåller Windows App SDK-beroenden.
  • Bekräfta att projektet matchar distributionsmodellen. För en normal opackad .NET-app innebär inställningen av <WindowsPackageType>None</WindowsPackageType> att automatisk initiering av Windows App SDK-körningen aktiveras. Använd bootstrapper-API:et direkt endast när du behöver explicit kontroll över dynamisk beroendeinitiering.

Mer information om distributionskrav finns i Distributionsappar som använder Windows App SDK.

Vad är skillnaden mellan WinUI 3 och WinUI 2 för UWP?

WinUI 3 är Microsoft nuvarande interna användargränssnittsramverk för Windows skrivbordsappar och levereras som en del av Windows App SDK.

WinUI 2, även kallat WinUI för UWP, är ett kontroll- och formatbibliotek för UWP-appar. WinUI 2 och WinUI 3 använder olika XAML-namnområden och är inte binärkompatibla.

Skapar jag en "WinUI-app" när jag skapar en app med Windows App SDK och WinUI 3?

Ja. WinUI 3-appen är den tydligaste termen för en app vars användargränssnitt använder WinUI 3 och Windows App SDK. WinUI-appen används också ofta när sammanhanget är tydligt.

Kan jag stegvis uppdatera min UWP-app med WinUI för UWP-kontroller till WinUI 3 genom att gradvis ersätta kontrollerna?

Nej. Windows App SDK kan inte användas i UWP-appar och WinUI för UWP kan inte blandas med WinUI 3. Se Migrera från UWP till Windows App SDK.

Hur svårt är det att migrera en UWP-app till WinUI 3?

UWP och WinUI 3 delar många XAML-begrepp, men migrering är inte en direkt namnområdesändring. Kostnaden beror främst på:

  1. Project fil och MSBuild-anpassning: Migreringsarbetet varierar beroende på avancerad MSBuild-användning.
  2. .NET API-migrering: UWP-appar som använder .NET Native kan flyttas till en .NET version som stöds med inbyggd AOT. Den här moderniseringen är separat från migrering av användargränssnittet till WinUI 3.
  3. Komponentbibliotek för användargränssnittet: Bibliotek måste ha versioner som riktar sig till WinUI 3.
  4. Fönster- och programmodell-API:er: UWP-API:er som är knutna till begrepp som CoreWindow, ApplicationVieweller GetForCurrentView kräver Windows App SDK ersättningar eller en annan skrivbordsmetod.
  5. C++-språkprojektion: Om UWP-appen använder den ersatta C++/CX-projektionen portar du koden till C++/WinRT.

Mer information finns i Migrera från UWP till Windows App SDK och API-mappning från UWP till Windows App SDK.

Kan jag publicera en ny paketerad WinUI 3-app med samma identifierare om jag har en befintlig UWP-app i Store?

Ja, uppgraderade appar kan publiceras utan att programidentiteten uppdateras. Användare av den gamla versionen uppdateras till den nya versionen. Detta gäller endast skrivbordsappar. Xbox, HoloLens och standardappar för Surface Hub kan inte migreras till WinUI 3.

Hur paketar eller distribuerar jag min WinUI 3-app?

Se Översikt över paket och distribution.

Var kan jag hitta vägledning för migrering av Windows App SDK?

Se Migrera från UWP till Windows App SDK.

Behöver jag använda XAML-kod om jag vill använda WinUI 3?

Nej. Användargränssnittskontroller kan skapas i kod. Att representera användargränssnittet i deklarativ XAML-markering ger dock många fördelar, inklusive en förbättrad utvecklarupplevelse.

  • Migrera från UWP till WinUI 3: Många XAML- och UI-begrepp överförs, men namnrymderna, projektmodellen och vissa API:er skiljer sig åt.
  • Migrera från WPF till WinUI 3: Många begrepp överförs, men kontrolluppsättningen och API:erna skiljer sig åt.
Har Visual Studio en designyta eller användargränssnittsdesigner för WinUI 3?

Inte för närvarande. Använd XAML-Hot Reload, Live Visual Tree, Live Property Explorer och relaterade körningsverktyg för att inspektera och uppdatera XAML medan appen körs.

En fullständig genomgång av de körningsdesignverktyg som är tillgängliga för WinUI 3 finns i Designverktyg för XAML-körning för WinUI 3.

Inkluderar Windows App SDK WinUI 3?

Ja. WinUI 3 levereras som en del av Windows App SDK.

Inkluderar Windows App SDK WinUI för UWP?

Nej. WinUI för UWP är en del av UWP-plattformen.

Bygger WinUI för UWP och WinUI 3 på samma teknik?

Inte riktigt. Även om WinUI 3 startades från WinUI för UWP-kodbasen är de distinkta tekniker. Båda är XAML-baserade gränssnittsramverk som fungerar i .NET och C++, men WinUI för UWP och WinUI 3 är inte kompatibla med varandra.

Kan jag använda WinUI 3 utan att använda Windows App SDK?

Nej. WinUI 3 levereras som en del av Windows App SDK.

Kan jag använda WinUI 3 i en uppackad app?

Ja. WinUI 3 och många Windows App SDK-API:er fungerar i opacketerade appar. Vissa Windows-funktioner kräver dock paketidentitet, och ramverksberoende opaketerade appar måste initiera Windows App SDK-körningen. Jämför alternativen i Paketeringsöversikt och Funktioner som kräver paketidentitet.

Vad är skillnaden mellan XAML-öarna och WinUI 3?

WinUI 3 är det användargränssnittsramverk som ingår i Windows App SDK. XAML Islands är en värdteknik som gör att en befintlig skrivbordsapp kan placera XAML-innehåll tillsammans med användargränssnittet från ett annat ramverk.

Termen kan avse äldre system-XAML Islands som är värdar för UWP XAML-kontroller, eller de WinUI XAML Islands som är värdar för Windows App SDK-kontroller i skrivbordsvärdar som stöds. API:erna, namnrymderna och värdkraven skiljer sig åt.

Kommer det att se modernt ut för både Windows 11 och Windows 10 om jag skapar en WinUI 3-app?

WinUI 3-kontrollelement använder Fluent-formatering i versioner av Windows 10 och Windows 11 som stöds, både i paketerade och opaketerade appar. Vissa operativsystemseffekter och beteenden skiljer sig åt beroende på Windows version. Mica är till exempel tillgängligt på Windows 11 och återgår till en fast färg på Windows 10.

Kan jag använda Mica- eller Akrylbakgrunder i appar som skapats med Windows App SDK?

Ja. Desktop Acrylic stöds på Windows 10 version 1809 och senare. Mica kräver Windows 11 och återgår till en solid temafärg på Windows 10. Anropa MicaController.IsSupported eller DesktopAcrylicController.IsSupported vid körning innan du tillämpar en bakgrund. Se Använd Mica- eller Akrylmaterial i skrivbordsappar för Windows 11.

Var hittar jag WinUI 3-exempel?

Se exempel och resurser. Några viktiga lagringsplatser:

Om jag redan har investerat mycket i WPF, bör jag fortsätta att använda WPF eller överväga att migrera till WinUI 3?

Om du redan har investerat mycket i WPF kan du fortsätta att använda det för befintliga appar. WPF är ett moget, stabilt ramverk som ofta används för att skapa Windows skrivbordsappar.

Använd GitHub Copilot uppgradering för att utvärdera och uppgradera en .NET Framework WPF-app till moderna .NET. Granska den genererade planen och verifiera varje ändring i din app.

Om jag skapar en ny WPF app ser den daterad ut jämfört med andra nya Windows appar?

När du utvecklar ett WPF program med .NET 9 eller senare kan du se till att din app matchar det eleganta, moderna utseendet på Windows 11. Det nya Fluent-temat för WPF introducerar ett modernt Windows 11 estetiskt, med integrerat ljust/mörkt läge och stöd för systemets accentfärg. Detta moderniserar appens utseende och ger en polerad, sammanhängande användarupplevelse.

Mitt team är bekvämt med att skapa WinForms-appar och det passar våra behov. Bör vi överväga att migrera till WinUI 3 eller något annat ramverk?

Om WinForms uppfyller dina behov och ditt team är bekvämt med det kan du fortsätta använda WinForms för befintliga appar. WinForms är ett moget och stabilt ramverk som ofta används för Windows skrivbordsutveckling.

WinForms-teamet fortsätter att investera i plattformen. Det senaste och pågående arbetet omfattar:

  • Asynkrona formulär- och dialog-API:er
  • Stöd för mörkt läge och visuella stilar
  • Förbättringar av hjälpmedel, hög DPI, layout och designer
  • Urklipp och DataObject modernisering

Plattformsoberoende utveckling

Vad är några orsaker till att skapa plattformsoberoende interna appar som riktar sig mot Windows?

Om du riktar dig till användare på flera os-plattformar kan det ge flera fördelar att skapa plattformsoberoende appar med .NET MAUI eller React Native:

  • Nå: Appar som fungerar på flera plattformar når en större målgrupp på olika enheter och operativsystem.
  • Återanvändning av kod: Om du återanvänder kod mellan plattformar minskar utvecklingstiden och kostnaderna. Det kan vara oöverkomligt dyrt att skapa separata appar för Windows, Android, iOS och macOS.
  • Konsekvent användarupplevelse: Plattformsoberoende ramverk ger ett konsekvent utseende på olika plattformar.
  • Integration: Plattformsoberoende appar kan fortfarande integreras med plattformsspecifika tjänster för att ge en omfattande upplevelse.
Kan jag vara säker på att .NET MAUI appar kommer att köras bra på Windows?

När du skapar en .NET MAUI app för Windows använder utdata WinUI 3. Under utvecklingen erbjuder .NET MAUI en enda .NET upplevelse på olika plattformar, men den genererar plattformsspecifik kod under huven.

Hur kan .NET MAUI tillhandahålla interna enhets-API:er för varje plattform?

.NET MAUI ger en enhetlig .NET upplevelse i Windows, iOS, Android och macOS. Den erbjuder plattformsoberoende API:er för vanliga funktioner som lagring, nätverk och enhetssensorer. Du kan också anropa plattformsspecifika API:er eller tillhandahålla specialiserade implementeringar för varje plattform.

Kan jag börja med WinUI 3 och senare integrera .NET MAUI om jag så småningom vill rikta in mig på plattformsoberoende scenarier?

Inte just nu. Även om .NET MAUI använder WinUI 3 när de körs på Windows, bör team som förväntar sig att rikta in sig på flera plattformar börja med .NET MAUI eller React Native for Desktop.

Vårt team har starka utvecklingskunskaper på klientsidan. Bör vi överväga att använda React Native för Desktop?

Team med stark webbutvecklingsupplevelse kanske vill överväga React Native for Desktop. Den innehåller React Native för Windows och macOS. Med metoden "Learn once, write anywhere" (Lär dig en gång, skriv var som helst) kan befintliga kunskaper i JavaScript, TypeScript och React användas för att skapa interna Windows- och macOS-appar.

React Native for Desktop renderar användargränssnittet direkt till inbyggda primitiver och levererar inbyggda prestanda- och plattformsfunktioner.

Se React Native for Desktop-dokumentationen för att komma igång.

Är andra Windows enheter som stöds av React Native for Desktop?

React Native för Windows stöder de Windows versioner som anges i dess kompatibilitetsdokumentation. Kontrollera enhetsfamiljens stöd för React Native för Windows version som du riktar in dig på i stället för att anta att varje Windows enhet stöds.

Vad ska jag använda om jag vill skapa appar som fungerar på Windows och Xbox?

För en Xbox-app använder du UWP och tar hänsyn till Xbox-specifika UWP-begränsningar. För spelutveckling använder du Microsoft Game Development Kit.

Vad ska jag använda om jag vill skapa appar som fungerar på Windows och Surface Hub?

För en Surface Hub som kör standardmiljön för Teams Rooms eller Surface Hub använder du en UWP-app som uppfyller kraven för Surface Hub-appen. En Surface Hub 3 som konfigurerats med Windows 11 Pro eller Enterprise kan köra skrivbordsapptekniker som stöds, så UWP är inte det enda alternativet i den konfigurationen.

Hybrid- och webbutveckling

Vad är hybridappar och varför bör jag överväga att skapa en?

Hybridappar blandar det bästa av webb- och intern apputveckling. Deras kärna bygger på webbtekniker som HTML, CSS och JavaScript och omsluts i en inbyggd container som ger access till vissa inbyggda plattformsfunktioner och maskinvara. De kan också distribueras via appbutiker.

Den största fördelen är att hybridappar gör att du kan skapa en enda app som kan köras på flera interna plattformar och på webben, vilket minskar utvecklingstiden och kostnaderna. Exempel på hybridappsutvecklingsplattformar är:

  • Elektron för skrivbordsappar
  • Ionic för mobilappar
  • .NET MAUI Blazor Hybrid för plattformsoberoende appar
Hur skapar jag progressiva webbappar (PWAs) som känns naturliga på Windows?

Se Webbutveckling på Windows och Översikt över Progressive Web Apps.

Vad är en .NET MAUI Blazor-hybridapp?

Med .NET MAUI kan Blazor-appar köras internt på Windows, iOS, Android och macOS. På så sätt kan du skapa hybridklientappar som kombinerar Blazor- och .NET MAUI-komponenter i en enda intern klientapp, med fullständig åtkomst till inbyggda plattformsfunktioner.

Läs mer på ASP.NET Core Blazor Hybrid.

Måste webbkomponenterna i en .NET MAUI hybridapp skapas med Blazor?

Nej. Från och med .NET 9 innehåller .NET MAUI en HybridWebView-kontroll som gör det möjligt att vara värd för andra JavaScript-baserade UIs i en inbyggd app.

På så sätt kan du vara värd för Angular, React, Vue eller andra HTML/JavaScript-appar i en .NET MAUI app. Hybridkontrollen ger interop mellan C# och JavaScript, så C#-kod kan anropa JavaScript-funktioner och vice versa.

Kan andra inbyggda apptyper vara värdar för Blazor-hybridkomponenter?

Ja. WPF- och WinForms-appar kan också vara värdar för Blazor-hybridkomponenter, vilket möjliggör tillägg av modernt webbgränssnitt till befintliga appar. Detta stöds inte för WPF- eller WinForms-appar som bygger på .NET Framework.

Behöver hela min app vara en hybridapp, eller kan jag blanda och matcha inbyggda komponenter och hybridkomponenter?

Inbyggda komponenter och hybridkomponenter kan blandas i en app. Kärnan i en app kan till exempel skapas med .NET MAUI komponenter medan hybridkomponenter ger ytterligare funktioner. På så sätt kan du kombinera prestanda och funktioner för inbyggda komponenter med flexibilitet och kostnadseffektivitet för hybridkomponenter.

Vad är mina val för att skapa .NET-baserade webbappar som ser bra ut i moderna webbläsare på Windows?

Web apps erbjuder den bredaste räckvidden för alla klientappsplattformar. Alternativ för att skapa snygga .NET webbappar är:

  • ASP.NET Core appar med Razor Pages
  • ASP.NET Core MVC-appar
  • ASP.NET Core Blazor-appar med värdmodellalternativ:
    • Blazor WebAssembly
    • Blazor Server

Blazor-värdmodeller kan nu konfigureras på komponentnivå, vilket möjliggör scenarier som att vara värd för en Blazor WebAssembly-komponent i en Blazor Server-app.

Mer information finns i dokumentationen ASP.NET Core.

Välj en metod och förstå Microsoft investeringar

Det finns så många ramverksalternativ för att skapa appar som är inriktade på Windows! Hur bestämmer jag?

Windows är en öppen plattform som stöder många tekniker. Här följer några kriterier som kan hjälpa dig att välja en plattform:

  • Bygger du Windows-först eller plattformsgemensamt?
  • Vilka språk eller kunskaper har du redan – .NET, JavaScript, något annat?
  • Behöver du åtkomst till Windows-specifika API:er?
  • Vilka ramverksfunktioner matchar bäst appens krav?
  • Se den här tabellen för ytterligare jämförelsefaktorer.

För många affärsappar väljer team ofta baserat på befintliga kunskaper och vad teamet är mest bekväma med att använda.

Hur väljer jag den bästa utvecklingsstrategin för min webbapp?

Tänk på följande när du väljer en utvecklingsmetod för din webbapp:

  • Blazor rekommenderas för att skapa klientwebbappar med .NET. Det gör att du kan skapa både klientdelen och serverdelen med hjälp av .NET, vilket sparar tid och kostnad, och det är särskilt bra för företagsappar.
  • JavaScript-webbappar är fortfarande meningsfulla om du vill utnyttja befintliga JavaScript-kunskaper eller behöver integrera med etablerade JavaScript-bibliotek eller ramverk.
  • Befintliga appar som använder äldre ramverk som Webbformulär, MVC eller Razor Pages stöds fortfarande och kan fortsätta att utvecklas och underhållas.
Vem skapar appar med WinUI 3 idag?

Microsoft Foton är ett dokumenterat exempel. Appen migrerades från UWP till Windows App SDK och fortsätter att använda WinUI 3. Mer information om arkitektur och migrering finns i Microsoft Foton: Migrera från UWP till Windows App SDK.

Who bygger .NET MAUI appar idag?

Organisationer använder .NET MAUI för att skapa plattformsoberoende appar för Android, iOS, macOS och Windows. Se exempel i .NET kundvisning.

Who bygger WPF appar idag?

Merparten av Microsoft Visual Studio användargränssnittet skapas med WPF. Själva Visual Studio IDE är ett stort exempel på en komplex WPF app med höga prestanda.

Vem skapar Blazor-appar idag?

GE Digitals FlightPulse flygbolagssystem använder Blazor för serverdelskonfigurationen av allt piloter ser, vilket ger sensordata och analys direkt till piloter för att förbättra säkerhet och effektivitet.

Se mer Blazor-kundberättelser på .NET webbplats.

Språkval (.NET jämfört med C++)

Ska jag använda C# eller C++ för min Windows app?

Använd C# (.NET) i de flesta fall. C# erbjuder snabbare utveckling, minnessäkerhet, omfattande bibliotek och utmärkta verktyg. De flesta Windows appar – inklusive WinUI 3, WPF, WinForms och .NET MAUI appar – är bäst byggda med C#.

Använd C++ när du behöver direkt maskinvaruåtkomst, minimala körningskostnader eller interop med befintliga C++-kodbaser. Vanliga C++-scenarier är spelmotorer (DirectX), drivrutiner, verktyg på systemnivå och prestandakritiska komponenter.

Faktor C# (.NET) C++
Utvecklingshastighet ✅ Snabbare – hanterat minne, omfattande ekosystem ⚠️ Långsammare – manuell resurshantering
Prestanda vid körning ✅Utmärkt med modern .NET (AOT, Span<T>) ✅ Bästa möjliga – inga GC-pauser
Minnessäkerhet ✅ Skräpinsamling ⚠️ Manuell – risk för läckor och sårbarheter
Windows API-åtkomst ✅ Via C#/WinRT-projektion ✅ Via C++/WinRT-projektion
WinUI 3-stöd ✅ Fullständigt stöd ✅ Fullständigt stöd via C++/WinRT
Flera plattformar ✅.NET körs på Windows, Linux, macOS ✅ Med plattformsspecifik kod
Bäst för Affärsappar, CRUD, tjänster, användargränssnittsintensiva appar Spel, drivrutiner, systemverktyg, kort svarstid

Du kan också blanda båda: skapa din app i C# och anropa prestandakritisk intern kod via P/Invoke (CsWin32) eller en C++/WinRT-komponent.

Hur anropar jag Win32-API:er från C#?

Använd CsWin32, en källgenerator som skapar typsäkra P/Invoke-signaturer vid bygget. Du lägger till Microsoft.Windows.CsWin32 NuGet-paketet, listar de API:er som du behöver i en NativeMethods.txt fil och anropar dem via en genererad PInvoke klass.

CsWin32 ersätter handskrivna [DllImport] deklarationer och fungerar i alla C#-projekt, inklusive WinUI 3, WPF, WinForms och konsolappar. En stegvis genomgång finns i Anropa Win32-API:er från en C# Windows-app (CsWin32).

Vad är C++/WinRT och när ska jag använda det?

C++/WinRT är en standard-C++17-språkprojektion för Windows Runtime API:er. Använd den när du skapar Windows appar i C++ som använder eller skapar WinRT-API:er. Den ersätter C++/CX och Windows Runtime C++ Template Library (WRL).

Välj C++/WinRT när:

  • Du skapar en C++ WinUI 3-app
  • Du måste skapa Windows Runtime komponenter som används av andra språk
  • Du porterar från C++/CX
Vad är C#/WinRT och när behöver jag det?

C#/WinRT har stöd för WinRT-projektion för C#. I de flesta fall interagerar du inte med det direkt — .NET-appar som riktar sig till Windows får automatiskt åtkomst till WinRT-API:er via målramverksidentifierare (TFM). Du behöver C#/WinRT explicit när du redigerar Windows Runtime komponenter i C# eller när du genererar interop-sammansättningar för WinRT-komponenter från tredje part.

Paketering, distribution och uppdateringar

Vad är skillnaden mellan appar som är paketerade, opacketerade och paketerade med extern plats?

En paketerad app innehåller dess filer, identitet och distributionsinformation i ett paket som MSIX. En opaketerad app använder ett installationsprogram eller en distributionsprocess utanför Windows paketsystem och saknar paketidentitet som standard. En app som paketeras med extern plats använder ett litet identitetspaket samtidigt som externa binärfiler bevaras och dess befintliga installationsprogram och uppdateringsprocess bevaras.

Se Paketeringsöversikt för krav och kompromisser.

Behöver jag paketidentitet?

Det beror på vilka Windows funktioner som appen använder. Paketidentitet krävs för scenarier som paketerade bakgrundsaktiviteter, resursmål, startuppgifter, anpassade snabbmenypakettillägg, manifestbaserade filtyps- och protokollassociationer och många Windows AI-API:er. Windows App SDK:s pushaviseringar har stöd för begränsade förgrundsscenarier utan appidentitet, men leverans i bakgrunden och COM-aktivering kräver identitet. WinUI 3- och lokala appmeddelanden kan fungera utan paketidentitet.

Se Funktioner som kräver paketidentitet. Om du behöver identitet men måste behålla ett befintligt installationsprogram bör du överväga att paketera med extern plats.

Vad är skillnaden mellan ramverksberoende och fristående distribution?

En ramverksberoende app använder Windows App SDK körningspaket som installeras separat på enheten. Detta minskar appens distributionsstorlek och låter det installerade ramverket ta emot underhållsuppdateringar. En fristående app bär med sig sina Windows App SDK beroenden, vilket ökar distributionsstorleken och gör apputgivaren ansvarig för att distribuera Windows App SDK serviceuppdateringar med nya appversioner.

API:er som är beroende av ytterligare MSIX-paket, till exempel Singleton-paketet, kan kräva separata distributions- eller körningsstödkontroller även i en fristående app. Paketering och distribution vid körning är separata beslut. Se Distributionsöversikt för Windows App SDK.

Kommer min WinUI 3-app automatiskt att uppdateras för slutanvändare?

En WinUI 3-app kan distribueras via Microsoft Store, en fil av typen .appinstaller eller ett MSI-paket eller installationsprogram. Store-paket kan uppdateras via underhåll i Microsoft Store, beroende på inställningar i Store och organisationen. En .appinstaller distribution stöder endast automatiska uppdateringar när den UpdateSettings konfigurerar starttid eller bakgrundskontroller. MSI- och setupdistributioner måste tillhandahålla eller integrera sin egen uppdateringsmekanism.

Kan jag använda Windows App SDK utan att använda MSBuild?

Ja, för vissa scenarier. WinUI 3 XAML-projekt kräver för närvarande MSBuild, men Visual Studio krävs inte och dotnet build kan anropa MSBuild från kommandoraden. Du kan använda icke-XAML-Windows App SDK API:er från C++ och CMake-projekt via förhandsversionen Windows App Development CLI eller integrera körningen manuellt.

Windows AI

Hur väljer jag mellan Windows AI-API:er, Foundry Local och Windows ML?

De tre första teknikerna ingår i Microsoft Foundry på Windows. Du kan kombinera dem med varandra och med molnmodeller i samma app:

  • Använd Windows AI-API:er för användningsklara funktioner vars modeller och maskinvaruacceleration Windows hanterar.
  • Använd Foundry Local för att identifiera, ladda ned och köra språk- och talmodeller med öppen källkod som stöds lokalt.
  • Använd Windows ML för att köra dina egna ONNX-modeller med körningsproviders för tillgänglig processor-, GPU- och NPU-maskinvara.
  • Använd Microsoft Foundry, en separat moln-AI-plattform, när du behöver molnbaserade modeller, hämtning, centraliserad styrning eller funktioner som inte är tillgängliga på målenheten.

Jämför alternativen i Välj din Windows AI-lösning. Överväg modellkapacitet, sekretess, anslutning, svarstid, maskinvarutäckning, distributionsstorlek och driftskostnader.

Kräver Windows AI-funktioner en Copilot+ PC?

Inte alla. Många Windows AI-API:er kräver en Copilot+ PC, men vissa API:er stöder även specifika GPU:er eller processorer. Foundry Local och Windows ML stöder ett bredare urval av maskinvarukonfigurationer, beroende på deras aktuella krav på operativsystem, modeller, körningsmiljöer och exekveringsprovidrar.

Kontrollera maskinvarutabellen Windows AI API och kraven för det specifika API:et eller modellen. Identifiera stöd och om modellen är redo under körning, och tillhandahåll ett reservalternativ utan AI, med lokal modell eller i molnet när funktionen inte är tillgänglig.

Kan Windows AI-funktioner köras lokalt och offline?

Ja. Windows AI-API:er, Foundry Local och Windows ML kan köra slutsatsdragning på användarens enhet, vilket kan minska svarstiden och hålla indata lokala. Vissa modeller eller körningsleverantörer måste först laddas ned eller provisioneras och kan kräva en internetanslutning vid installation eller service. Ai-molntjänster kräver anslutning och skickar data till tjänsten enligt dess villkor för datahantering.

Berätta för användarna när en modellnedladdning krävs och när data lämnar enheten. Beskriv inte en funktion som att den kan användas offline förrän du har testat hela upplevelsen vid förstagångsanvändning, uppdatering och reservlösning.

Kan AI-verktyg hjälpa mig att skapa eller modernisera en Windows app?

Ja. AI-kodningsagenter kan hjälpa till att skapa projekt, förklara API:er, migrera kod, generera tester och diagnostisera byggproblem. Använd utvecklingsvägledningen för AI-assisterad Windows för GitHub Copilot, WinUI-agentens plugin-program, Microsoft Learn MCP Server, arbetsflöden för migrering och AI-assisterad testning.

Granska och testa genererad kod på samma sätt som andra bidrag. Kontrollera i synnerhet API-namn och versioner, paketfunktioner, säkerhetskänslig kod, hjälpmedel och eventuella UWP-till-WinUI 3-ersättningar.

Vad bör jag tänka på innan jag skickar en AI-assisterad funktion?

Definiera funktionens avsedda användning och begränsningar, utvärdera kvalitet och säkerhet med representativa data, avslöja AI-beteende där det är lämpligt, skydda användardata och ge en reserv när modellen eller nödvändig maskinvara inte är tillgänglig. Håll hemligheter och privilegierade tjänstautentiseringsuppgifter borta från klientappar och kräv användarbekräftelse innan efterföljande eller oåterkalleliga åtgärder. Se Ansvarsfull generativ AI-utveckling om Windows och säkerhet och ansvarsfull AI för Windows utveckling.

Prestanda och optimering

Vad kan jag göra för att min Windows app ska kännas bra för slutanvändarna?

Se Windows programutveckling – Metodtips och Windows översikt över appprestanda och grunderna.

Compatibility

Kommer mina användare någonsin att behöva uppdatera Windows för att använda min WinUI 3-app?

Windows App SDK har ett minimikrav på kompatibelt operativsystem: Windows 10, version 1809, build 17763. Microsoft support kräver en Windows App SDK version som stöds med den senaste underhållsuppdateringen och en Windows-version, version och servicekanal som fortfarande stöds. Enskilda API:er kan kräva en nyare Windows version eller specifik maskinvara. Se support för Windows App SDK och utgivningskanaler.

Kan jag rikta in mig på Arm64 med min WinUI 3-app?

Ja. Skapa en inbyggd Arm64-app för bästa prestanda och effektivitet. För en stor C++-kodbas med x64-beroenden kan du med Arm64EC migrera moduler stegvis. Windows 11 på Arm kan också köra många befintliga x86- och x64-appar via Prism-emulering, men du bör testa prestanda och kompatibilitet på representativa Arm-enheter.

Utfasningar och migreringar

Är UWP/WinUI för UWP inaktuellt?

UWP och WinUI 2 är inte formellt inaktuella. Visual Studio 2026 stöder UWP med modern .NET och intern AOT, medan WinUI 2.8 fortfarande är den senaste stabila WinUI-versionen för UWP. Men Microsoft rekommenderar WinUI 3 och Windows App SDK för nya allmänna Windows skrivbordsappar.

UWP-stöd för moderna .NET med intern AOT är allmänt tillgängligt och är standardprojekttypen C# UWP i Visual Studio 2026. Att flytta en befintlig UWP-app från .NET Native till modern .NET är ett separat moderniseringssteg från migrering av användargränssnittet till WinUI 3. Se Modernisera din UWP-app med .NET och intern AOT.

När ska jag migrera en UWP/WinUI för UWP-app till WinUI 3?

UWP-utvecklare bör inte känna sig pressade att migrera om de är nöjda med UWP och dess funktionsuppsättning – för många appar kan rätt val vara att stanna på UWP.

Appar som vill dra nytta av den senaste Windows plattform och .NET investeringar bör överväga att flytta till WinUI 3 och Windows App SDK. Se Migrera från UWP till Windows App SDK.

När ska jag *inte* migrera en UWP + WinUI för UWP-app till WinUI 3?

Fortsätt att använda UWP när målenheten eller appmodellen kräver det, till exempel Xbox appar, HoloLens 2D-appar eller appar för standardmiljön för Surface Hub. Windows IoT Enterprise stöder teknik för skrivbordsappar, inklusive Windows App SDK, så ett IoT-mål är inte i sig en anledning att använda UWP.

Är WPF föråldrat?

Nej. WPF stöds och fortsätter att ta emot funktions-, prestanda-, tillgänglighets- och Fluent-stilförbättringar i moderna .NET. Det är fortfarande ett bra val för befintliga WPF appar och för nya appar vars krav passar WPF. För nya allmänna Windows skrivbordsappar är Microsoft främsta rekommendation WinUI 3 med Windows App SDK. Se WPF-färdplanen på GitHub.

Är WinForms inaktuellt?

Nej. WinForms stöds och fortsätter att ta emot funktionsuppdateringar. Se Windows Forms Vägkarta på GitHub.

Är Windows Runtime (WinRT) inaktuellt?

Nej. WinRT är ett program binärt gränssnitt (ABI) som möjliggör interop över flera språk. WinRT är utvecklingen av COM, och Windows App SDK tillhandahåller de flesta av dess funktioner via WinRT-API:er.

Versionsmeddelanden

Var hittar jag versionsinformation för Windows App SDK?

Se versionsinformationen för Windows App SDK för information om stabila versioner, förhandsversioner och experimentella versioner. Sidan Nyheter för Windows utvecklare sammanfattar den senaste Windows SDK, Windows App SDK, WinUI 3, verktyg och plattformsuppdateringar.

Relaterat innehåll

  • Last updated on