Rilasciato Microsoft Windows App SDK 1.0 stabile, disponibile per il download (Note sulla versione)

Dopo diverse build di anteprima, Microsoft ha appena rilasciato Windows App SDK 1.0.0 Stable, un toolkit che consente agli sviluppatori di app desktop di creare app con un'interfaccia utente Windows moderna, API e funzionalità della piattaforma.

In questa versione, Microsoft ha aggiunto diverse nuove funzionalità da Windows App SDK 0.8 e ha stabilizzato i problemi dalle versioni di anteprima 1.0.

[lwptoc title=”WindowsAppSDK 1.0 stabile” width=”30%” float=”destra”]

Interfaccia utente di Windows 3

WinUI 3 è il framework dell'esperienza utente (UX) nativa per Windows App SDK.

Nuove funzionalità e aggiornamenti:

• Microsoft ha aggiunto nuovi controlli (PipsPager, Expander, BreadcrumbBar) e aggiornato i controlli esistenti per riflettere gli ultimi stili di Windows da Interfaccia utente di Windows 2.6.
• La creazione di pacchetti MSIX a progetto singolo è supportata in WinUI creando una nuova applicazione utilizzando il modello "App vuota, con pacchetto...".
• Microsoft ora supporta la distribuzione di app WinUI 3 senza pacchetto MSIX su Windows versioni 1809 e successive. Si prega di visualizzare Crea un'app desktop non imballata WinUI 3 per ulteriori informazioni.
• I progetti WinUI 3 ora possono impostare la loro versione di destinazione fino a Windows 10, versione 1809. In precedenza, potevano essere impostati solo a partire dalla versione 1903.
• In Visual Studio 2022 Preview 5 e GA sono supportati barra degli strumenti in-app, Hot Reload e Live Visual Tree per le app in pacchetto WinUI.

Limitazioni importanti:

• Problemi noti per applicazioni WinUI sia impacchettate che non imballate:
  • Errore di runtime nelle app C++ che fanno riferimento a un componente di Windows Runtime C++: Per risolvere, aggiungi la destinazione seguente alla fine del .vcxproj del componente Windows Runtime:

    XMLCopia

    <Target Name="GetPriIndexName">
    <PropertyGroup>
        <!-- Winmd library targets use the default root namespace of the project for the App package name -->
        <PriIndexName Condition="'$(RootNamespace)' != ''">$(RootNamespace)</PriIndexName>
        <!-- If RootNamespace is empty fall back to TargetName -->
        <PriIndexName Condition="$(PriIndexName) == ''">$(TargetName)</PriIndexName>
    </PropertyGroup>
    </Target>
    

• Problemi noti per Applicazioni WinUI con MSIX a progetto singolo (App vuota, modello in pacchetto):
  • Voce di menu Pacchetto e pubblicazione mancante fino al riavvio di Visual Studio: Quando si crea una nuova app con MSIX a progetto singolo in Visual Studio 2019 e Visual Studio 2022 usando il modello di progetto App vuota, Packaged (WinUI 3 in Desktop), il comando per pubblicare il progetto non viene visualizzato nel menu fino alla chiusura e riapri Visual Studio.
  • L'app AC# con MSIX a progetto singolo non verrà compilata senza il componente facoltativo "C++ (v14x) Universal Windows Platform Tools" installato. Visualizzazione Installa strumenti per sviluppatori per ulteriori informazioni.
  • Potenziale errore di runtime in un'app con MSIX a progetto singolo che utilizza i tipi definiti in un componente di Windows Runtime di riferimento: Per risolvere, aggiungi manualmente voci di classe attivabili in appxmanifest.xml.
    • L'errore previsto nelle applicazioni C# è "COMException: Classe non registrata (0x80040154 (REGDB_E_CLASSNOTREG)).
    • L'errore previsto nelle applicazioni C++/WinRT è "winrt::hresult_class_not_registered".
• Problemi noti per Applicazioni WinUI senza pacchetto MSIX (app non imballate):
  • Alcune API richiedono l'identità del pacchetto e non sono supportate nelle app decompresse, ad esempio:
    • Dati dell'applicazione
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • Informazioni API (non supportato su Windows 10)
    • Pacchetto.Corrente
    • Qualsiasi API nel Windows.ApplicationModel.Resources namespace
    • Qualsiasi API nel Microsoft.Windows.ApplicationModel.Resources namespace
• Problemi noti per confezionamento e distribuzione di applicazioni WinUI:
  • I Package Il comando non è supportato nelle app WinUI con MSIX a progetto singolo (app vuota, modello in pacchetto). Invece, usa il Package & Publish comando per creare un pacchetto MSIX.
  • Per creare un pacchetto NuGet da una libreria di classi C# con l'estensione Pack comando, assicurarsi che sia attivo Configuration is Release.
  • I Pack comando non è supportato nei componenti di Windows Runtime C++ per creare un pacchetto NuGet.

windowing

Windows App SDK fornisce un Finestra dell'applicazione classe che evolve la precedente classe di anteprima di facile utilizzo Windows.UI.WindowManagement.AppWindow e la rende disponibile per tutte le app di Windows, inclusi Win32, WPF e WinForms.

Nuove funzionalità

• Finestra dell'applicazione è un'API di windowing di alto livello che consente scenari di windowing di facile utilizzo che si integrano bene con l'esperienza utente di Windows e con altre app. Rappresenta un'astrazione di alto livello di un contenitore gestito dal sistema del contenuto di un'app. Questo è il contenitore in cui sono ospitati i tuoi contenuti e rappresenta l'entità con cui gli utenti interagiscono quando ridimensionano e spostano la tua app sullo schermo. Per gli sviluppatori che hanno familiarità con Win32, AppWindow può essere visto come un'astrazione di alto livello di HWND.
• Area espositiva rappresenta un'astrazione di alto livello di un HMONITOR, segue gli stessi principi di AppWindow.
• DisplayAreaWatcher consente a uno sviluppatore di osservare i cambiamenti nella topologia di visualizzazione ed enumerare le DisplayAreas attualmente definite nel sistema.

Ingresso

Queste sono le API di input che supportano WinUI e forniscono una superficie API di livello inferiore per consentire agli sviluppatori di ottenere interazioni di input più avanzate.

Nuove funzionalità

• API puntatore: Puntatore, Proprietà PointerPointe PointEventArgs per supportare il recupero delle informazioni sugli eventi del puntatore con le API di input XAML.
• API InputPointerSource: rappresenta un oggetto registrato per segnalare l'input del puntatore e fornisce il cursore del puntatore e la gestione degli eventi di input per l'API SwapChainPanel di XAML.
• API cursore: consente agli sviluppatori di modificare la bitmap del cursore.
• API GestureRecognizer: consente agli sviluppatori di riconoscere determinati gesti come trascinare, tenere premuto e fare clic quando vengono fornite informazioni sul puntatore.

Limitazioni importanti

• Tutti Puntatore le funzioni statiche di fabbrica sono state rimosse: OttieniPuntoAttuale, OttieniPuntoCorrenteTrasformato, Ottieni punti intermedie Ottieni punti intermedi trasformati.
• Windows App SDK non supporta il recupero Puntatore oggetti con ID puntatore. Invece, puoi usare il Puntatore funzione membro OttieniPuntoTrasformato per recuperare una versione trasformata di un esistente Puntatore oggetto. Per i punti intermedi, puoi usare il PointEventArgs funzioni membro Ottieni punti intermedi ed OttieniPunti Intermedi Trasformati.
• Utilizzo diretto dell'API SDK della piattaforma Windows.UI.Core.CoreDragOperation non funzionerà con le applicazioni WinUI.
• Puntatore proprietà Posizione grezza ed ContattoRectRaw sono stati rimossi perché si riferivano a valori non previsti, che erano gli stessi dei valori normali nel sistema operativo. Uso Posizione ed ContattoRect invece. La previsione del puntatore ora viene gestita con il Microsoft.UI.Input.PointerPredictor Oggetto API.

Ciclo di vita dell'app

La maggior parte delle funzionalità del ciclo di vita dell'app esiste già nella piattaforma UWP e sono state introdotte in Windows App SDK per l'uso da parte di tipi di app desktop, in particolare app console senza pacchetto, app Win32, app Windows Forms e app WPF. L'implementazione di Windows App SDK di queste funzionalità non può essere usata nelle app UWP, poiché sono presenti funzionalità equivalenti nella piattaforma UWP stessa.

Le app non UWP possono anche essere inserite in pacchetti MSIX. Sebbene queste app possano usare alcune delle funzionalità del ciclo di vita dell'app di Windows App SDK, devono usare l'approccio manifest se disponibile. Ad esempio, non possono utilizzare Windows App SDK RegisterForXXXAttivazione API e devono invece registrarsi per l'attivazione avanzata tramite il manifest.

Tutti i vincoli per le app in pacchetto si applicano anche alle app WinUI, che sono in pacchetto, e ci sono considerazioni aggiuntive come descritto di seguito.

Considerazioni importanti:

• Attivazione ricca: GetActivatedEventArgs
  • App non imballate: Completamente utilizzabile.
  • App in pacchetto: utilizzabile, ma queste app possono anche utilizzare la piattaforma GetActivatedEventArgs. Si noti che la piattaforma definisce Windows.ApplicationModel.AppInstance mentre Windows App SDK definisce Microsoft.Windows.AppLifecycle.AppInstance. E mentre le app UWP possono usare il ActivatedEventArgs classi, come FileActivatedEventArgs ed LaunchActivatedEventArgs, le app che utilizzano la funzionalità AppLifecycle di Windows App SDK devono utilizzare le interfacce e non le classi (ad es. IFileActivatedEventArgs, ILaunchActivatedEventArgs, e così via).
  • App WinUi: App.OnLaunched di WinUI riceve a Microsoft.UI.Xaml.LaunchActivatedEventArgs, mentre la piattaforma GetActivatedEventArgs restituisce a Windows.ApplicationModel.IActivatedEventArgse WindowsAppSDK GetActivatedEventArgs restituisce a Microsoft.Windows.AppLifecycle.AppActivationArguments oggetto che può rappresentare una piattaforma LaunchActivatedEventArgs.
  • Per maggiori informazioni, vedi Attivazione ricca.
• Registrati/Annulla registrazione per l'attivazione avanzata
  • App non imballate: Completamente utilizzabile.
  • App in pacchetto: non utilizzabile, usa invece il manifest MSIX dell'app.
  • Per maggiori informazioni, vedi Attivazione ricca.
• Istanza singola/multipla
  • App non imballate: Completamente utilizzabile.
  • App in pacchetto: Completamente utilizzabile.
  • App WinUI: Se un'app desidera rilevare altre istanze e reindirizzare un'attivazione, deve farlo il prima possibile e prima di inizializzare qualsiasi finestra, ecc. Per abilitarlo, l'app deve definire DISABLE_XAML_GENERATED_MAIN e scrivere un Main personalizzato (C#) o WinMain (C++) dove può eseguire il rilevamento e il reindirizzamento.
  • ReindirizzamentoAttivazioneAsync è una chiamata asincrona e non dovresti attendere una chiamata asincrona se l'app è in esecuzione in una STA. Per le app Windows Forms e C# WinUI, puoi dichiarare Main come asincrono, se necessario. Per le app C++ WinUI e C# WPF, non puoi dichiarare che Main sia asincrono, quindi devi spostare la chiamata di reindirizzamento su un altro thread per assicurarti di non bloccare la STA.
  • Per maggiori informazioni, vedi Istanziazione dell'app.
• Notifiche di stato/potenza
  • App non imballate: Completamente utilizzabile.
  • App in pacchetto: Completamente utilizzabile.
  • Per maggiori informazioni, vedi Risparmio energetico.

Problema conosciuto:

• Le associazioni dei tipi di file codificano in modo errato %1 come %251 quando si imposta il modello della riga di comando del gestore Verb, che provoca l'arresto anomalo delle app Win32 decompresse. Puoi modificare manualmente il valore del Registro di sistema in modo che sia %1 come soluzione alternativa parziale. Se il percorso del file di destinazione contiene uno spazio, non riuscirà comunque e non esiste una soluzione alternativa per quello scenario.
• Questi bug di istanze singole/multipli verranno corretti in una prossima patch di manutenzione:
  • Il reindirizzamento di AppInstance non funziona se compilato per x86
  • La registrazione di una chiave, l'annullamento della registrazione e la registrazione di nuovo provocano l'arresto anomalo dell'app

Scrivi Core

DWriteCore è l'implementazione di Windows App SDK di DirectWrite, che è l'API DirectX per il rendering del testo di alta qualità, caratteri di struttura indipendenti dalla risoluzione e supporto completo per testo e layout Unicode. DWriteCore è una forma di DirectWrite che funziona su versioni di Windows fino a Windows 10, versione 1809 (10.0; Build 17763) e apre le porte all'utilizzo multipiattaforma.

Caratteristiche DWriteCore contiene tutte le funzionalità di DirectWrite, con alcune eccezioni.

Limitazioni importanti

• DWriteCore non contiene le seguenti funzionalità di DirectWrite:
  • Caratteri per sessione
  • Caratteri definiti dall'utente finale (EUDC).
  • API per lo streaming dei caratteri
• Il supporto dell'API di rendering di basso livello è parziale.
• DWriteCore non interagisce con Direct2D, ma è possibile utilizzarlo IDWriteGlyphRunAnalysis ed IDWriteBitmapRenderTarget.

Nucleo MRT

MRT Core è una versione semplificata del moderno Windows Sistema di gestione delle risorse distribuito come parte di Windows App SDK.

Limitazioni importanti

• Nei progetti .NET, i file di risorse copiati e incollati nella cartella del progetto non vengono indicizzati su F5 se l'app è già stata compilata. Come soluzione alternativa, ricostruisci l'app. Vedere problema 1503 per maggiori informazioni.
• Nei progetti .NET, quando un file di risorse viene aggiunto al progetto utilizzando l'interfaccia utente di Visual Studio, i file potrebbero non essere indicizzati per impostazione predefinita. Vedere problema 1786 per maggiori informazioni. Per aggirare questo problema, rimuovere le voci seguenti nel file CSPROJ:

  XMLCopia

  <ItemGroup>
      <Content Remove="<image file name>" />
  </ItemGroup>
  <ItemGroup>
      <PRIResource Remove="<resw file name>" />
  </ItemGroup>
  

• Per le app WinUI C++ non imballate, l'URI della risorsa non è compilato correttamente. Per aggirare questo problema, aggiungere quanto segue in vcxproj:

  XMLCopia

  <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->
  
  <PropertyGroup>
      <AppxPriInitialPath></AppxPriInitialPath>   
  </PropertyGroup>
  

Distribuzione

Nuove funzionalità e aggiornamenti

• Puoi inizializzare automaticamente Windows App SDK tramite il WindowsPackageType project per caricare il runtime di Windows App SDK e chiamare le API di Windows App SDK. Vedere Crea un'app WinUI 3 per le istruzioni.
• Le app decompresse possono distribuire Windows App SDK integrandosi in Windows App SDK autonomo .exe installer nell'MSI esistente o nel programma di installazione. Per ulteriori informazioni, vedere Guida alla distribuzione di Windows App SDK per le app decompresse.
• Le app .NET non imballate possono anche usare il wrapper .NET per il API bootstrap per assumere dinamicamente una dipendenza dal pacchetto del framework Windows App SDK in fase di esecuzione. Per ulteriori informazioni sul wrapper .NET, vedere Libreria wrapper .NET.
• Le app in pacchetto possono utilizzare l'API di distribuzione per verificare e assicurarsi che tutti i pacchetti richiesti siano installati sulla macchina. Per ulteriori informazioni su come funziona l'API di distribuzione, vedere il guida alla distribuzione per le app in pacchetto.

Limitazioni importanti

• Il wrapper .NET per l'API bootstrapper è inteso solo per l'uso da parte di applicazioni .NET decompresse per semplificare l'accesso a Windows App SDK.
• Solo le app in pacchetto MSIX che sono completamente attendibili o hanno l'estensione gestione dei pacchetti la capacità limitata dispone dell'autorizzazione per utilizzare l'API di distribuzione per installare le dipendenze del pacchetto principale e singleton. Il supporto per le app in pacchetto con attendibilità parziale arriverà nelle versioni successive.
• Quando F5 testa un'app x86 che utilizza il file DeploymentManager.Inizializza metodo su un sistema x64, assicurarsi che il framework x64 sia prima installato eseguendo il file WindowsAppRuntimeInstall.exe. Altrimenti, incontrerai a NON TROVATO errore dovuto al fatto che Visual Studio non distribuisce il framework x64, che normalmente si verifica tramite la distribuzione dello Store o il sideload.

Altre limitazioni e problemi noti

• Nessun supporto per qualsiasi configurazione di build della CPU: Quando aggiunta di Windows App SDK a un'applicazione .NET esistente o un componente che supporta Qualsiasi CPU, è necessario specificare l'architettura desiderata: x86, x64 or arm64.
• Aggiornamento da .NET 5 a .NET 6: durante l'aggiornamento nell'interfaccia utente di Visual Studio, potrebbero verificarsi errori di compilazione. Come soluzione alternativa, aggiorna manualmente il pacchetto TargetFrameworkPackage del tuo file di progetto al seguente:

  XMLCopia

      <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework> 
  

• L'app MSIX per progetto singolo C# non viene compilata se gli strumenti UWP C++ non sono installati. Se hai un progetto MSIX C# a progetto singolo, dovrai installare il file Strumenti universali della piattaforma Windows C++ (v14x). componente opzionale.
• La lingua successiva VSIX non viene installata in Visual Studio 2019 quando sono installate più versioni di Visual Studio 2019. Se hai più versioni di Visual Studio 2019 installate (ad es. Release e Preview), quindi installa Windows App SDK VSIX per entrambi C++ ed C#, la seconda installazione avrà esito negativo. Per risolvere, disinstallare gli strumenti di packaging MSIX a progetto singolo per Visual Studio 2019 dopo la prima lingua VSIX. Visualizzazione questo feedback per ulteriori informazioni su questo problema.
• Se desideri co_await sul DispatcherQueue.TryEnqueue metodo, quindi utilizzare il curriculum_in primo piano funzione di supporto nel Libreria di implementazione di Windows (WIL):
  1. Aggiungi un riferimento a Libreria di implementazione di Microsoft.Windows Pacchetto NuGet.
  2. Aggiungere il #include <wil/cppwinrt_helpers.h> dichiarazione nel file di codice.
  3. Usa il  wil::resume_foreground(your_dispatcher); a co_await il risultato.

Leggi di più e trova i link per il download su Microsoft qui.