domande frequenti sullo sviluppo di app di Windows

Per una panoramica delle opzioni attuali per gli sviluppatori di Windows, guardare l'episodio Windows Dev Chat Scelta della piattaforma di sviluppo ideale, che illustra WinUI 3, .NET MAUI, React Native, Blazor e progressive App Web (PWA). Puoi trovare altri episodi nella playlist Windows Dev Chat.

È anche possibile fare riferimento al panoramica delle opzioni di sviluppo di app per sviluppatori di Windows.

Nell'era dei servizi cloud, lo sviluppo di app client rimane importante per offrire interazioni reattive e significative nei dispositivi degli utenti.

Ecco perché le app client sono importanti:

• Copertura del dispositivo: Le app client consentono di portare l'applicazione direttamente agli utenti nei dispositivi scelti.
• Gateway ai Servizi Intelligenti: Le applicazioni client sono spesso il primo punto di contatto degli utenti con i tuoi servizi. Offrono un'interfaccia ricca e interattiva che consente di presentare funzionalità intelligenti e differenziare il prodotto dagli altri.
• Scalability with Cloud Integration: Un'app client ben integrata può essere sincronizzata senza problemi con i cloud services back-end, consentendo access di dati in tempo reale e scalabilità senza problemi man mano che la base utente cresce.
• produttività avanzata e fedeltà degli utenti: Un'app progettata in modo ponderato può migliorare la produttività e mantenere gli utenti impegnati con il prodotto o il servizio nel tempo.

Il SDK per app di Windows fornisce componenti gestiti in modo indipendente per le app desktop Windows, tra cui WinUI 3, ciclo di vita dell'app, finestra, notifiche, risorse e API di testo. Supporta le app eseguite in Windows 10, versione 1809 e successive, soggette al ciclo di vita del supporto della versione Windows e SDK per app di Windows.

Entrambi sono sdk (Software Development Kit) che consentono di creare app Windows.

Il SDK per app di Windows fornisce componenti forniti in modo indipendente da Windows e funzionano nelle versioni Windows supportate fino a Windows 10, versione 1809. Include WinUI 3 e API per il ciclo di vita dell'app, la finestra, le notifiche, le risorse, il testo e altre funzionalità.

L'SDK di Windows fornisce intestazioni, librerie, metadati e strumenti per le API del sistema operativo, ad esempio Win32, WinRT, COM, DirectX, dispositivi e funzionalità della shell.

Il SDK per app di Windows non sostituisce Windows SDK. Le app che adottano il SDK per app di Windows possono continuare a usare le API SDK Windows e le app WinUI 3 usano in genere entrambi.

Ecco alcuni motivi per scegliere un framework di Windows nativo per l'app solo Windows:

• Performance: Framework di Windows nativi sono ottimizzati per sfruttare l'hardware Windows moderno, offrendo esperienze utente veloci e reattive.
• Integration: Windows include un'ampia gamma di API che consentono esperienze sofisticate disponibili solo in Windows. I framework nativi offrono un'integrazione approfondita con queste funzionalità e API.
• Native user experience: Framework nativi offrono un'esperienza coerente tra i dispositivi Windows, assicurando che l'app abbia un aspetto ottimale ovunque.
• Supporto offline: I framework nativi supportano scenari offline, consentendo alle app di funzionare anche senza connettività Internet.
• Supporto e strumenti: Microsoft gestisce i framework nativi e fornisce SDK, documentazione, strumenti di debug ed esempi correnti.

Se stai creando una nuova app desktop per utilizzo generico Windows, ti consigliamo di usare WinUI 3. WinUI 3 è il framework dell'interfaccia utente nativo fornito con il SDK per app di Windows. Supporta Windows app desktop e fornisce l'accesso ai controlli Fluent correnti e alle funzionalità della piattaforma Windows.

Si noti che WinUI 3 (un framework dell'interfaccia utente) viene fornito con il SDK per app di Windows (un framework di sviluppo della piattaforma Windows).

Puoi eseguire la migrazione dell'interfaccia utente di un'app a WinUI 3 o usare le isole XAML WinUI per ospitare SDK per app di Windows controlli in un host desktop esistente supportato. Le isole XAML del sistema legacy ospitano controlli XAML UWP e usano API diverse.

Gli elementi del SDK per app di Windows possono essere spesso usati nelle app desktop, a seconda della modalità di compilazione dell'app esistente. Le app UWP non sono supportate da SDK per app di Windows.

Ciò significa che le app macchine virtuali Windows/MFC/WinForms possono usare SDK per app di Windows API non correlate a WinUI 3. Gli esempi includono il ciclo di vita dell'app, la finestra e le notifiche delle app.

Per altre informazioni, vedi Usare il SDK per app di Windows in un progetto esistente.

No Le compilazioni XAML winUI 3 usano MSBuild, ma è possibile compilare con i modelli .NET SDK e WinUI 3 correnti dalla riga di comando in un altro editor. Consulta la guida rapida alla riga di comando.

Visual Studio 2026 offre l'esperienza di modifica, debug, profilatura e Ricaricamento rapido XAML più ricca. Usa il flusso di lavoro che corrisponde ai requisiti dei tuoi strumenti.

Questo errore si verifica in genere negli scenari di app unpackaged in cui il runtime di SDK per app di Windows non è stato installato nel computer. Provare quanto segue:

• Se si esegue un'app packaged (impostazione predefinita consigliata), assicurarsi di avviarsi tramite Visual Studio con MsixPackage profilo di avvio selezionato (non con il profilo eseguibile normale). Il passaggio di creazione pacchetti MSIX installa i componenti di runtime necessari.
• Se si esegue un'app senza pacchetto dipendente dal framework, installa il runtime di SDK per app di Windows corrispondente. Una distribuzione autonoma include le relative dipendenze SDK per app di Windows.
• Verificare che il progetto corrisponda al modello di distribuzione. Per un'app normale .NET non in pacchetto, l'impostazione <WindowsPackageType>None</WindowsPackageType> abilita SDK per app di Windows l'inizializzazione automatica del runtime. Usare direttamente l'API del programma di avvio automatico solo quando è necessario un controllo esplicito sull'inizializzazione delle dipendenze dinamiche.

Per altre informazioni sui requisiti di distribuzione, vedere App di distribuzione che usano il SDK per app di Windows.

WinUI 3 è l'attuale framework nativo dell'interfaccia utente di Microsoft per le app desktop di Windows ed è fornito come parte di SDK per app di Windows.

WinUI 2, chiamato anche WinUI per UWP, è una libreria di controlli e stili per le app UWP. WinUI 2 e WinUI 3 usano spazi dei nomi XAML diversi e non sono compatibili con i file binari.

Sì. L'app WinUI 3 è il termine più chiaro per un'app la cui interfaccia utente usa WinUI 3 e la SDK per app di Windows. L'app WinUI viene usata comunemente anche quando il contesto non è ambiguo.

No SDK per app di Windows non può essere usato nelle app UWP e WinUI per UWP non può essere combinato con WinUI 3. Vedi Migrate dalla piattaforma UWP al SDK per app di Windows.

UWP e WinUI 3 condividono molti concetti XAML, ma la migrazione non è una modifica diretta dello spazio dei nomi. Il costo dipende principalmente da:

1. Project file e personalizzazione di MSBuild: Il lavoro di migrazione varia a seconda dell'utilizzo avanzato di MSBuild.
2. migrazione api .NET: le app UWP che usano .NET Native possono passare a una versione di .NET attualmente supportata con AOT nativo. Questa modernizzazione è separata dalla migrazione dell'interfaccia utente a WinUI 3.
3. Librerie dei componenti dell'interfaccia utente: Le librerie devono avere versioni destinate a WinUI 3.
4. API di gestione delle finestre e del modello di applicazione: Le API UWP legate a concetti come CoreWindow, ApplicationView o GetForCurrentView richiedono sostituzioni in SDK per app di Windows o un diverso approccio desktop.
5. Proiezione del linguaggio C++: Se l'app UWP usa la proiezione C++/CX sostituita, convertire il codice in C++/WinRT.

Per ulteriori informazioni, vedere Eseguire la migrazione da UWP a SDK per app di Windows e il mapping delle API da UWP a SDK per app di Windows.

Sì, le app aggiornate possono essere pubblicate senza aggiornare l'identità dell'applicazione. Gli utenti della versione precedente verranno aggiornati alla nuova versione. Questo vale solo per le app desktop. Xbox, HoloLens e le app hub standard Surface non possono eseguire la migrazione a WinUI 3.

Consulta Cenni preliminari sulla distribuzione.

Vedi Migrate dalla piattaforma UWP al SDK per app di Windows.

No I controlli dell'interfaccia utente possono essere creati nel codice. Tuttavia, la rappresentazione dell'interfaccia utente nel markup XAML dichiarativo offre molti vantaggi, tra cui un'esperienza di sviluppo migliorata.

• Migrazione da UWP a WinUI 3: molti concetti di XAML e dell'interfaccia utente rimangono validi, ma i namespace, il modello di progetto e alcune API sono diversi.
• Migrazione da macchine virtuali Windows a WinUI 3: molti concetti rimangono validi, ma l'insieme di controlli e le API sono diversi.

Attualmente, no. Usa XAML Ricaricamento rapido, Albero visuale dinamico, Esplora proprietà dinamico e i relativi strumenti di runtime per ispezionare e aggiornare lo XAML mentre l'app è in esecuzione.

Per una procedura dettagliata completa degli strumenti di progettazione di runtime disponibili per WinUI 3, vedi Strumenti di progettazione del runtime XAML per WinUI 3.

Sì. WinUI 3 viene fornito come parte di SDK per app di Windows.

No WinUI per UWP fa parte della piattaforma UWP.

Non esattamente. Anche se WinUI 3 è stato avviato dalla codebase di WinUI per UWP, sono tecnologie distinte. Entrambi sono framework dell'interfaccia utente basati su XAML che funzionano tra .NET e C++, ma WinUI per UWP e WinUI 3 non sono compatibili tra loro.

No WinUI 3 viene fornito come parte di SDK per app di Windows.

Sì. WinUI 3 e molte API SDK per app di Windows funzionano in app non in pacchetto. Tuttavia, alcune funzionalità di Windows richiedono l'identità del pacchetto e le app non in pacchetto dipendenti dal framework devono inizializzare il runtime SDK per app di Windows. Confrontare le opzioni in Panoramica dei pacchetti e Funzionalità che richiedono l'identità del pacchetto.

WinUI 3 è il framework dell'interfaccia utente incluso nel SDK per app di Windows. Le isole XAML sono una tecnica di hosting che consente a un'app desktop esistente di inserire contenuto XAML insieme all'interfaccia utente di un altro framework.

Il termine può fare riferimento alle isole XAML di sistema legacy che ospitano controlli XAML UWP o alle isole XAML WinUI che ospitano SDK per app di Windows controlli negli host desktop supportati. Le API, gli spazi dei nomi e i requisiti dell'host differiscono.

I controlli WinUI 3 usano stili Fluent nelle versioni supportate di Windows 10 e Windows 11, sia nelle app in pacchetto che non in pacchetto. Alcuni effetti e comportamenti del sistema operativo differiscono per Windows versione. Ad esempio, Mica è disponibile su Windows 11 e, in alternativa, su Windows 10 viene usato un colore uniforme.

Sì. L'acrilico desktop è supportato in Windows 10 versione 1809 e successive. Mica richiede Windows 11 e su Windows 10 ripiega su un colore uniforme. Richiamare MicaController.IsSupported o DesktopAcrylicController.IsSupported in fase di esecuzione prima di applicare uno sfondo. Vedi Applica i materiali Mica o acrilici nelle app desktop per Windows 11.

Vedere Esempi e risorse. Alcuni repository rilevanti:

• WindowsAppSDK-Samples: illustra come usare set di API SDK per app di Windows specifici.
• Esempi di Windows specifici per argomento: contiene l'esempio usato nel tutorial Creare un'app per le note in WinUI 3.
• WinUI 3 Gallery: Presenta WinUI e SDK per app di Windows. Disponibile anche nel Microsoft Store.

Se hai già investito molto in macchine virtuali Windows, puoi continuare a usarlo per le app esistenti. macchine virtuali Windows è un framework maturo e stabile ampiamente usato per creare app desktop Windows.

Usa l'aggiornamento di GitHub Copilot per valutare e aggiornare un'app macchine virtuali Windows basata su .NET Framework alla versione moderna di .NET. Esaminare il piano generato e convalidare ogni modifica nell'app.

Quando si sviluppa un'applicazione macchine virtuali Windows con .NET 9 o versione successiva, è possibile assicurarsi che l'app corrisponda all'aspetto elegante e moderno dei Windows 11. Il nuovo tema Fluent per macchine virtuali Windows introduce un'estetica Windows 11 contemporanea, con la modalità Light/Dark integrata e il supporto del colore principale del sistema. In questo modo l'aspetto dell'app viene modernizzato e offre un'esperienza utente lucida e coerente.

Se WinForms soddisfa le tue esigenze e il tuo team è a tuo agio con esso, puoi continuare a usare WinForms per le app esistenti. WinForms è un framework maturo e stabile ampiamente usato per lo sviluppo di applicazioni desktop Windows.

Il team di WinForms continua a investire nella piattaforma. Il lavoro recente e continuativo include:

• API asincrone di moduli e finestre di dialogo
• Supporto per la modalità scura e lo stile visivo
• Miglioramenti all'accessibilità, ai valori DPI elevati, al layout e alla finestra di progettazione
• Appunti e DataObject modernizzazione

Se stai puntando agli utenti su più piattaforme operative, lo sviluppo di applicazioni multipiattaforma con .NET MAUI o React Native può offrire diversi vantaggi:

• Raggiungere: Le app multipiattaforma raggiungono un pubblico più ampio tra dispositivi e sistemi operativi diversi.
• Riutilizzo del codice: Il riutilizzo del codice tra piattaforme riduce i tempi e i costi di sviluppo. La compilazione di app separate per Windows, Android, iOS e macOS può essere eccessivamente costosa.
• Esperienza utente coerente: I framework multipiattaforma consentono di offrire un aspetto coerente tra le piattaforme.
• Integrazione: Le app multipiattaforma possono comunque integrarsi con servizi specifici della piattaforma per offrire un'esperienza completa.

Quando si compila un'app .NET MAUI per Windows, l'output usa WinUI 3. Durante lo sviluppo, .NET MAUI offre una singola esperienza di .NET su più piattaforme, ma genera codice specifico della piattaforma sotto le quinte.

.NET MAUI offre un'esperienza unificata di .NET in Windows, iOS, Android e macOS. Offre API multipiattaforma per funzionalità comuni, ad esempio archiviazione, rete e sensori di dispositivo. È anche possibile chiamare API specifiche della piattaforma o fornire implementazioni specializzate per ogni piattaforma.

Non in questo momento. Anche se .NET MAUI usa WinUI 3 durante l'esecuzione in Windows, i team che prevedono la destinazione di più piattaforme devono iniziare con .NET MAUI o React Native for Desktop.

I team con un'esperienza di sviluppo Web avanzata possono voler prendere in considerazione React Native for Desktop. Include React Native per Windows e macOS. Con l'approccio "Learn once, write anywhere", è possibile usare le competenze JavaScript, TypeScript e React esistenti per creare app native Windows e macOS.

React Native for Desktop esegue il rendering dell'interfaccia utente direttamente in primitive native, offrendo funzionalità native di prestazioni e piattaforma.

Per iniziare, vedere la documentazione di React Native for Desktop.

React Native per Windows supporta le versioni Windows elencate nella relativa documentazione sulla compatibilità. Verifica la compatibilità con la famiglia di dispositivi per la versione di React Native per Windows che intendi usare, invece di dare per scontato che tutti i dispositivi Windows siano supportati.

Per un'app Xbox, usa UWP e tieni conto delle limitazioni UWP specifiche di Xbox. Per lo sviluppo di giochi, usare il Kit di sviluppo giochi Microsoft.

Per un hub Surface che esegue Teams Rooms standard o Surface hub, usa un'app UWP che soddisfi i requisiti dell'app hub Surface. Un Surface Hub 3 configurato con Windows 11 Pro o Enterprise può eseguire tecnologie di app desktop supportate, quindi la piattaforma UWP non è l'unica opzione in tale configurazione.

Le app ibride combinano il meglio dello sviluppo di app Web e native. Il loro nucleo è costruito utilizzando tecnologie web come HTML, CSS e JavaScript ed è incapsulato in un contenitore nativo che fornisce accesso a determinate funzionalità e all'hardware della piattaforma host. Possono anche essere distribuiti tramite app store.

Il vantaggio principale è che le app ibride consentono di creare una singola app che può essere eseguita su più piattaforme native e sul Web, riducendo i tempi e i costi di sviluppo. Esempi di piattaforme di sviluppo di app ibride includono:

• Electron per le applicazioni desktop
• Ionic per le app per dispositivi mobili
• .NET MAUI Blazor Hybrid per le app multipiattaforma

Consulta Web development on Windows e Overview of Progressive App Web.

Con .NET MAUI, le app Blazor possono essere eseguite in modo nativo in Windows, iOS, Android e macOS. In questo modo è possibile creare app client ibride che combinano componenti Blazor e .NET MAUI in un'unica app client nativa, con accesso completo alle funzionalità della piattaforma nativa.

Per altre informazioni, vedere ASP.NET Core Blazor Hybrid.

No A partire da .NET 9, .NET MAUI include un controllo HybridWebView che consente di ospitare altre interfacce utente basate su JavaScript all'interno di un'app nativa.

In questo modo è possibile ospitare Angular, React, Vue o altre app HTML/JavaScript all'interno di un'app .NET MAUI. Il controllo ibrido fornisce interoperabilità tra C# e JavaScript, quindi il codice C# può chiamare funzioni JavaScript e viceversa.

Sì. macchine virtuali Windows e le app WinForms possono anche ospitare componenti ibridi Blazor, consentendo l'aggiunta dell'interfaccia utente Web moderna alle app esistenti. Questa opzione non è supportata per le app macchine virtuali Windows o WinForms basate su .NET Framework.

I componenti nativi e ibridi possono essere misti all'interno di un'app. Ad esempio, il nucleo di un'app può essere compilato con componenti .NET MAUI mentre i componenti ibridi forniscono funzionalità aggiuntive. Ciò consente di combinare le prestazioni e le funzionalità dei componenti nativi con la flessibilità e l'efficienza dei costi dei componenti ibridi.

Le web app offrono la portata massima di qualunque piattaforma di app client. Le opzioni per la creazione di app Web .NET belle includono:

• app ASP.NET Core con Razor Pages
• ASP.NET Core applicazioni MVC
• ASP.NET Core app Blazor, con opzioni del modello di hosting:
  • Blazor WebAssembly
  • Blazor Server

I modelli di hosting Blazor possono ora essere configurati a livello di componente, abilitando scenari come l'hosting di un componente WebAssembly Blazor all'interno di un'app Blazor Server.

Per altre informazioni, vedere la documentazione ASP.NET Core.

Windows è una piattaforma aperta che supporta molte tecnologie. Ecco alcuni criteri che consentono di scegliere una piattaforma:

• Stai sviluppando prima Windows oppure multipiattaforma?
• Quali linguaggi o competenze si hanno già: .NET, JavaScript, qualcos'altro?
• È necessario accedere alle API specifiche di Windows?
• Quali funzionalità del framework soddisfano meglio i requisiti dell'app?
• Per altri fattori di confronto, vedere questa tabella .

Per molte app aziendali, i team spesso scelgono in base alle competenze esistenti e a ciò che il team è più comodo usare.

Quando si sceglie un approccio di sviluppo per l'app Web, tenere presente quanto segue:

• Blazor è consigliato per la creazione di app Web front-end con .NET. Consente di creare sia il front-end che il back-end usando .NET, risparmiando tempo e costi ed è particolarmente utile per le app aziendali.
• Le applicazioni web in JavaScript hanno ancora senso se si vogliono sfruttare le competenze esistenti in JavaScript o se è necessario integrarsi con librerie o framework JavaScript consolidati.
• Le app esistenti che usano framework meno recenti come Web Form, MVC o Razor Pages rimangono supportate e possono continuare a essere sviluppate e gestite.

Microsoft Foto è un esempio documentato. L'app è stata migrata dalla piattaforma UWP alla SDK per app di Windows e continua a usare WinUI 3. Per informazioni dettagliate sull'architettura e la migrazione, vedi Microsoft Foto: Migrazione da UWP a SDK per app di Windows.

Le organizzazioni usano .NET MAUI per creare app multipiattaforma per Android, iOS, macOS e Windows. Vedere esempi nella presentazione dei clienti .NET.

La maggior parte dell'interfaccia utente di Microsoft Visual Studio è compilata con macchine virtuali Windows. L'IDE Visual Studio è un esempio principale di un'app macchine virtuali Windows complessa e ad alte prestazioni.

GE Digital FlightPulse sistema per compagnie aeree usa Blazor per la configurazione back-end di tutto ciò che i piloti vedono, portando direttamente ai piloti i dati dei sensori e l'analisi per migliorare la sicurezza e l'efficienza.

Guarda altre storie dei clienti Blazor sul sito di .NET.

Usare C# (.NET) nella maggior parte dei casi. C# offre sviluppo, sicurezza della memoria, librerie avanzate e strumenti eccellenti. La maggior parte delle app di Windows, incluse quelle WinUI 3, macchine virtuali Windows, WinForms e .NET MAUI, si sviluppa al meglio con C#.

Usare C++ quando è necessario l'accesso diretto all'hardware, il sovraccarico di runtime minimo o l'interoperabilità con codebase C++ esistenti. Gli scenari C++ comuni includono motori di gioco (DirectX), driver, utilità a livello di sistema e componenti critici per le prestazioni.

Fattore	C# (.NET)	C++
Velocità di sviluppo	✅ Più veloce: memoria gestita, ecosistema ricco	⚠️ Più lento : gestione manuale delle risorse
Prestazioni di runtime	✅Eccellente con .NET moderno (AOT, Span<T>)	✅ Il massimo possibile — nessuna pausa GC
Sicurezza della memoria	✅ Con garbage collection	⚠️ Manuale : rischio di perdite e vulnerabilità
Accesso a Windows API	✅ Mediante la proiezione C#/WinRT	✅ Mediante la proiezione C++/WinRT
Supporto di WinUI 3	✅ Supporto completo	✅ Supporto completo tramite C++/WinRT
Multipiattaforma	✅.NET in esecuzione in Windows, Linux, macOS	✅ Con codice specifico della piattaforma
Migliore per	App aziendali, CRUD, servizi, app pesanti per l'interfaccia utente	Giochi, driver, strumenti di sistema, bassa latenza

È anche possibile combinare entrambe le opzioni: compilare l'app in C# e chiamare codice nativo critico per le prestazioni tramite P/Invoke (CsWin32) o un componente C++/WinRT.

Usa CsWin32, un generatore di codice sorgente che crea firme P/Invoke tipizzate in modo sicuro in fase di build. Aggiungere il Microsoft.Windows.CsWin32 pacchetto NuGet, elencare le API necessarie in un NativeMethods.txt file e chiamarle tramite una classe generata PInvoke .

CsWin32 sostituisce le dichiarazioni scritte [DllImport] a mano e funziona in qualsiasi progetto C#, tra cui WinUI 3, macchine virtuali Windows, WinForms e app console. Per una guida dettagliata, vedi Chiamare le API Win32 da un'app Windows C# (CsWin32).

C++/WinRT è una proiezione di linguaggio C++17 standard per le API di Windows Runtime. Usarlo quando si creano app Windows in C++ che usano o creano API WinRT. Sostituisce C++/CX e la libreria di modelli C++ Windows Runtime (WRL).

Scegliere C++/WinRT quando:

• Stai creando un'app WinUI 3 in C++
• È necessario creare dei componenti di Windows Runtime usati da altri linguaggi
• Stai effettuando il porting da C++/CX

C#/WinRT offre supporto per la proiezione WinRT per C#. Nella maggior parte dei casi non si interagisce direttamente con esso — le app .NET destinate a Windows ottengono automaticamente l'accesso alle API WinRT tramite i moniker del framework di destinazione (TFM). È necessario C#/WinRT in modo esplicito quando si creano componenti Windows Runtime in C# o quando si generano assembly di interoperabilità per i componenti WinRT di terze parti.

Un'app in pacchetto contiene i file, l'identità e le informazioni di distribuzione in un pacchetto, ad esempio MSIX. Un'app senza pacchetto usa un programma di installazione o un processo di distribuzione al di fuori del sistema di pacchetti di Windows e non dispone per impostazione predefinita di un'identità di pacchetto. Un'app pacchettizzata con percorso esterno utilizza un piccolo pacchetto di identità, mantenendo i file binari archiviati esternamente e il programma di installazione e il processo di aggiornamento esistenti.

Vedi Panoramica del packaging per requisiti e compromessi.

Dipende dalle funzionalità Windows usate dall'app. L'identità del pacchetto è necessaria per scenari quali attività in background in pacchetto, condivisione di destinazioni, attività di avvio, estensioni del pacchetto di menu di scelta rapida personalizzate, associazioni di tipo di file e protocolli basate su manifesto e molte API di intelligenza artificiale Windows. Le notifiche push in SDK per app di Windows supportano scenari limitati in primo piano senza identità, ma il recapito in background e l'attivazione COM richiedono un'identità. Le notifiche delle app locali e WinUI 3 possono funzionare senza identità del pacchetto.

Vedere Funzionalità che richiedono l'identità del pacchetto. Se è necessaria un'identità, ma deve conservare un programma di installazione esistente, prendere in considerazione la creazione di pacchetti con una posizione esterna.

Un'app dipendente dal framework usa SDK per app di Windows pacchetti di runtime installati separatamente nel dispositivo. Ciò riduce le dimensioni della distribuzione dell'app e consente al framework installato di ricevere gli aggiornamenti di manutenzione. Un'app autonoma include le relative dipendenze SDK per app di Windows, aumentando le dimensioni della distribuzione e facendo in modo che l'autore dell'app sia responsabile della distribuzione degli aggiornamenti di manutenzione SDK per app di Windows con nuove versioni dell'app.

Le API che dipendono da pacchetti MSIX aggiuntivi, ad esempio il pacchetto Singleton, possono richiedere controlli di supporto di distribuzione o runtime separati anche in un'app autonoma. La creazione di pacchetti e la distribuzione in fase di esecuzione sono decisioni separate. Vedere Panoramica della distribuzione di SDK per app di Windows.

Un'app WinUI 3 può essere distribuita tramite il Microsoft Store, un .appinstaller file o un file MSI o un eseguibile di installazione. I pacchetti dello Store possono essere aggiornati tramite la gestione degli aggiornamenti di Microsoft Store, in base alle impostazioni di Microsoft Store e dell'organizzazione. Una .appinstaller distribuzione supporta gli aggiornamenti automatici solo quando il relativo UpdateSettings configura controlli all’avvio o in background. Le distribuzioni MSI e quelle tramite programma di installazione devono fornire o integrare un proprio sistema di aggiornamento.

Sì, per alcuni scenari. I progetti XAML WinUI 3 richiedono attualmente MSBuild, anche se Visual Studio non è obbligatorio e dotnet build possono richiamare MSBuild dalla riga di comando. È possibile usare le API di SDK per app di Windows non XAML nei progetti C++ e CMake tramite l'anteprima app di Windows Development CLI oppure integrare manualmente il runtime.

Le prime tre tecnologie fanno parte di Microsoft Foundry su Windows. È possibile combinarli tra loro e con i modelli cloud nella stessa app:

• Usare Windows API di intelligenza artificiale per funzionalità pronte all'uso i cui modelli e accelerazione hardware Windows gestisce.
• Usare Foundry Local per individuare, scaricare ed eseguire modelli di riconoscimento vocale e lingua open source supportati in locale.
• Usare Windows ML per eseguire modelli ONNX personalizzati con provider di esecuzione per l'hardware di CPU, GPU e NPU disponibile.
• Usare Microsoft Foundry, una piattaforma di intelligenza artificiale cloud separata, quando sono necessari modelli ospitati nel cloud, recupero, governance centralizzata o funzionalità non disponibili nel dispositivo di destinazione.

Confrontare le opzioni in Scegliere la soluzione di intelligenza artificiale Windows. Prendere in considerazione funzionalità del modello, privacy, connettività, latenza, copertura hardware, dimensioni della distribuzione e costi operativi.

Non tutti. Molte API di intelligenza artificiale Windows richiedono un Copilot+ PC, ma alcune API supportano anche GPU o CPU specifiche. Foundry Local e Windows ML supportano configurazioni hardware più ampie, soggette ai requisiti correnti del sistema operativo, del modello, del runtime e del provider di esecuzione.

Controllare la tabella hardware dell'API di intelligenza artificiale Windows e i requisiti per l'API o il modello specifico. Rilevare il supporto e la prontezza del modello in fase di esecuzione e fornire un fallback non basato sull'IA, su modello locale o su cloud quando la funzionalità non è disponibile.

Sì. Windows API di intelligenza artificiale, Foundry Local e Windows ML possono eseguire inferenza nel dispositivo dell'utente, riducendo la latenza e mantenendo i dati di input locali. Alcuni modelli o provider di esecuzione devono prima essere scaricati o predisposti e possono richiedere una connessione a Internet durante la configurazione o la manutenzione. I servizi di intelligenza artificiale cloud richiedono la connettività e inviano dati al servizio in base alle condizioni di gestione dei dati.

Indicare agli utenti quando è necessario il download di un modello e quando i dati lasciano il dispositivo. Non descrivere una funzionalità come compatibile con l’uso offline finché non hai testato completamente l’esperienza di primo avvio, di aggiornamento e di fallback.

Sì. Gli agenti di codifica di intelligenza artificiale possono aiutare a eseguire lo scaffolding dei progetti, spiegare le API, eseguire la migrazione del codice, generare test e diagnosticare i problemi di compilazione. Usa la guida per sviluppo di Windows assistito dall'intelligenza artificiale per GitHub Copilot, il plug-in dell'agente WinUI, il server MCP di Microsoft Learn, i flussi di lavoro di migrazione e i test assistiti dall'intelligenza artificiale.

Esaminare e testare il codice generato come qualsiasi altro contributo. In particolare, verificare i nomi e le versioni delle API, le funzionalità dei pacchetti, il codice sensibile alla sicurezza, l'accessibilità e tutte le sostituzioni UWP-to-WinUI 3.

Definire l'uso e le limitazioni previste della funzionalità, valutare la qualità e la sicurezza con i dati rappresentativi, divulgare il comportamento di intelligenza artificiale, se appropriato, proteggere i dati utente e fornire un fallback quando il modello o l'hardware richiesto non è disponibile. Mantenere i segreti e le credenziali del servizio con privilegi all'esterno delle app client e richiedere la conferma dell'utente prima di azioni consequenziali o irreversibili. Vedere Sviluppo di intelligenza artificiale generativa responsabile su Windows e sicurezza e intelligenza artificiale responsabile per lo sviluppo di Windows.

Vedi Sviluppo di applicazioni Windows - Migliori pratiche e Panoramica sulle prestazioni e sui fondamenti delle app Windows.

Il SDK per app di Windows ha un sistema operativo compatibile minimo di Windows 10, versione 1809, build 17763. Il supporto Microsoft richiede una versione supportata di SDK per app di Windows con l'ultimo aggiornamento della manutenzione e un'edizione, una versione e un canale di manutenzione di Windows ancora supportati. Le singole API possono richiedere una versione Windows più recente o hardware specifico. Vedi supporto per SDK per app di Windows e canali di rilascio.

Sì. Creare un'app Arm64 nativa per ottenere prestazioni ed efficienza ottimali. Per una codebase C++ di grandi dimensioni con dipendenze x64, Arm64EC consente di eseguire la migrazione incrementale dei moduli. Windows 11 arm può anche eseguire molte app x86 e x64 esistenti tramite emulazione prism, ma è consigliabile testare le prestazioni e la compatibilità nei dispositivi Arm rappresentativi.

UWP e WinUI 2 non sono formalmente deprecati. Visual Studio 2026 supporta la piattaforma UWP con .NET moderne e AOT native, mentre WinUI 2.8 rimane la versione stabile più recente di WinUI per la piattaforma UWP. Tuttavia, Microsoft consiglia WinUI 3 e la SDK per app di Windows per le nuove app desktop per utilizzo generico Windows.

Il supporto UWP per i .NET moderni con AOT nativo è disponibile a livello generale ed è il tipo di progetto UWP C# predefinito in Visual Studio 2026. Lo spostamento di un'app UWP esistente da .NET Native a .NET moderna è un passaggio di modernizzazione separato dalla migrazione dell'interfaccia utente a WinUI 3. Vedi Modernizzare l'app UWP con .NET e AOT nativo.

Gli sviluppatori UWP non devono sentirsi sottoposti a pressione per eseguire la migrazione se sono soddisfatti della piattaforma UWP e del set di funzionalità: per molte app, la scelta giusta può essere quella di rimanere nella piattaforma UWP.

Le app che vogliono trarre vantaggio dalla piattaforma Windows più recente e dagli investimenti in .NET dovrebbero valutare il passaggio a WinUI 3 e a SDK per app di Windows. Vedi Migrate dalla piattaforma UWP al SDK per app di Windows.

Continuare a usare la piattaforma UWP quando il modello di app o il dispositivo di destinazione lo richiede, ad esempio app Xbox, app HoloLens 2D o app per l'ambiente hub Surface standard. Windows IoT Enterprise supporta tecnologie per le app desktop, tra cui la SDK per app di Windows, quindi una destinazione IoT non è per sé un motivo per usare la piattaforma UWP.

No macchine virtuali Windows è supportato e continua a ricevere miglioramenti di funzionalità, prestazioni, accessibilità e fluent style nelle .NET moderne. Rimane una buona scelta per le app macchine virtuali Windows esistenti e per le nuove app i cui requisiti rientrano macchine virtuali Windows. Per le nuove app desktop Windows per uso generico, la raccomandazione principale di Microsoft è WinUI 3 con SDK per app di Windows. Consulta la roadmap macchine virtuali Windows su GitHub.

No WinForms è supportato e continua a ricevere gli aggiornamenti delle funzionalità. Consulta la roadmap Windows Forms su GitHub.

No WinRT è un'interfaccia ABI (Application Binary Interface) che consente l'interoperabilità tra più linguaggi. WinRT è l'evoluzione di COM e il SDK per app di Windows offre la maggior parte delle sue funzionalità tramite le API WinRT.

Vedere le note sulla versione SDK per app di Windows per le versioni stabili, di anteprima e sperimentali. La pagina Novità per gli sviluppatori di Windows riepiloga gli aggiornamenti più recenti di Windows SDK, SDK per app di Windows, WinUI 3, strumenti e piattaforma.