Lançamento do Microsoft Windows App SDK 1.0 Stable, disponível para download (Notas de lançamento)

Após várias compilações de visualização, a Microsoft acaba de lançar o Windows App SDK 1.0.0 Stable, um kit de ferramentas que capacita os desenvolvedores de aplicativos de desktop a criar aplicativos com uma interface de usuário moderna do Windows, APIs e recursos de plataforma.

Nesta versão, a Microsoft adicionou vários novos recursos do Windows App SDK 0.8 e estabilizou os problemas das versões 1.0 Preview.

[lwptoc title=”WindowsAppSDK 1.0 Estável” largura=”30%” float=”right”]

WindowsUI 3

WinUI 3 é a estrutura nativa de experiência do usuário (UX) para Windows App SDK.

Novos recursos e atualizações:

• A Microsoft adicionou novos controles (PipsPager, Expander, BreadcrumbBar) e atualizou os controles existentes para refletir os estilos mais recentes do Windows WindowsUI 2.6.
• O empacotamento MSIX de projeto único é suportado no WinUI criando um novo aplicativo usando o modelo “Aplicativo em branco, empacotado…”.
• A Microsoft agora oferece suporte à implantação de aplicativos WinUI 3 sem pacote MSIX nas versões 1809 e superiores do Windows. Por favor veja Criar um aplicativo de desktop não empacotado do WinUI 3 para obter informações adicionais.
• Os projetos do WinUI 3 agora podem definir sua versão de destino para o Windows 10, versão 1809. Anteriormente, eles só podiam ser definidos para a versão 1903.
• Barra de ferramentas no aplicativo, Hot Reload e Live Visual Tree para aplicativos empacotados WinUI são compatíveis com Visual Studio 2022 Preview 5 e GA.

Limitações importantes:

• Problemas conhecidos para aplicativos WinUI empacotados e não empacotados:
  • Erro de tempo de execução em aplicativos C++ que fazem referência a um componente C++ do Windows Runtime: Para resolver, adicione o destino abaixo ao final do .vcxproj do Windows Runtime Component:

    XMLCopiar

    <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>
    

• Problemas conhecidos para Aplicativos WinUI com MSIX de projeto único (Aplicativo em branco, modelo empacotado):
  • Item de menu Package & Publish ausente até que você reinicie o Visual Studio: Ao criar um novo aplicativo com MSIX de projeto único no Visual Studio 2019 e no Visual Studio 2022 usando o modelo de projeto Aplicativo em branco, empacotado (WinUI 3 na área de trabalho), o comando para publicar o projeto não aparece no menu até você fechar e reabra o Visual Studio.
  • O aplicativo AC# com MSIX de projeto único não será compilado sem o componente opcional “C++ (v14x) Universal Windows Platform Tools” instalado. Visualizar Instalar ferramentas de desenvolvedor para obter informações adicionais.
  • Possível erro de tempo de execução em um aplicativo com MSIX de projeto único que consome tipos definidos em um componente de tempo de execução do Windows referenciado: Para resolver, adicione manualmente entradas de classe ativáveis para o appxmanifest.xml.
    • O erro esperado em aplicativos C# é “COMException: Classe não registrada (0x80040154 (REGDB_E_CLASSNOTREG)).
    • O erro esperado em aplicativos C++/WinRT é “winrt::hresult_class_not_registered”.
• Problemas conhecidos para Aplicativos WinUI sem pacote MSIX (aplicativos não empacotados):
  • Algumas APIs exigem identidade de pacote e não são compatíveis com aplicativos não empacotados, como:
    • Dados de aplicativos
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • Informações da API (não suportado no Windows 10)
    • Pacote.Atual
    • Qualquer API no Windows.ApplicationModel.Resources namespace
    • Qualquer API no Microsoft.Windows.ApplicationModel.Resources namespace
• Problemas conhecidos para empacotar e implantar aplicativos WinUI:
  • A Package O comando não tem suporte em aplicativos WinUI com MSIX de projeto único (aplicativo em branco, modelo empacotado). Em vez disso, use o Package & Publish comando para criar um pacote MSIX.
  • Para criar um pacote NuGet de uma biblioteca de classes C# com o Pack comando, assegure o ativo Configuration is Release.
  • A Pack O comando não tem suporte em componentes de tempo de execução do Windows C++ para criar um pacote NuGet.

Janelas

O Windows App SDK fornece uma Janela de aplicativos classe que evolui a classe de visualização Windows.UI.WindowManagement.AppWindow anterior fácil de usar e a disponibiliza para todos os aplicativos do Windows, incluindo Win32, WPF e WinForms.

Novos Recursos

• Janela de aplicativos é uma API de janelas de alto nível que permite cenários de janelas fáceis de usar que se integram bem à experiência do usuário do Windows e a outros aplicativos. Representa uma abstração de alto nível de um contêiner gerenciado pelo sistema do conteúdo de um aplicativo. Este é o contêiner no qual seu conteúdo está hospedado e representa a entidade com a qual os usuários interagem quando redimensionam e movem seu aplicativo na tela. Para desenvolvedores familiarizados com Win32, o AppWindow pode ser visto como uma abstração de alto nível do HWND.
• Area de exposição representa uma abstração de alto nível de um HMONITOR, segue os mesmos princípios do AppWindow.
• DisplayAreaWatcher permite que um desenvolvedor observe as alterações na topologia de exibição e enumere as DisplayAreas atualmente definidas no sistema.

Entrada

Essas são as APIs de entrada que oferecem suporte ao WinUI e fornecem uma superfície de API de nível inferior para os desenvolvedores obterem interações de entrada mais avançadas.

Novos Recursos

• APIs de ponteiro: PonteiroPonto, Propriedades PointerPoint e PointEventArgs para dar suporte à recuperação de informações de eventos de ponteiro com APIs de entrada XAML.
• API InputPointerSource: representa um objeto registrado para relatar a entrada do ponteiro e fornece o cursor do ponteiro e a manipulação do evento de entrada para a API SwapChainPanel do XAML.
• API do cursor: permite que os desenvolvedores alterem o bitmap do cursor.
• API de reconhecimento de gestos: permite que os desenvolvedores reconheçam certos gestos, como arrastar, segurar e clicar quando receberem informações de ponteiro.

Limitações importantes

• Todos os Produtos PonteiroPonto funções de fábrica estáticas foram removidas: Obter Ponto Atual, GetCurrentPointTransformado, Obter Pontos Intermediários e GetIntermediatePointsTransformado.
• O Windows App SDK não oferece suporte à recuperação PonteiroPonto objetos com IDs de ponteiro. Em vez disso, você pode usar o PonteiroPonto função de membro GetTransformedPoint para recuperar uma versão transformada de um existente PonteiroPonto objeto. Para pontos intermediários, você pode usar o PointEventArgs funções de membro Obter Pontos Intermediários e GetTransformedIntermediatePoints.
• Uso direto da API do SDK da plataforma Windows.UI.Core.CoreDragOperation não funcionará com aplicativos WinUI.
• PonteiroPonto Propriedades Posição Bruta e ContatoRectRaw foram removidos porque se referiam a valores não previstos, que eram os mesmos que os valores normais na OS. Usar Posição e ContatoRect em vez de. A previsão de ponteiro agora é tratada com o Microsoft.UI.Input.PointerPredictor objeto de API.

Ciclo de vida do aplicativo

A maioria dos recursos do Ciclo de Vida do Aplicativo já existe na plataforma UWP e foi trazida para o SDK do Aplicativo do Windows para uso por tipos de aplicativos de desktop, especialmente aplicativos de console não empacotados, aplicativos Win32, aplicativos Windows Forms e aplicativos WPF. A implementação do Windows App SDK desses recursos não pode ser usada em aplicativos UWP, pois há recursos equivalentes na própria plataforma UWP.

Aplicativos não UWP também podem ser empacotados em pacotes MSIX. Embora esses aplicativos possam usar alguns dos recursos do Windows App SDK App Lifecycle, eles devem usar a abordagem de manifesto onde estiver disponível. Por exemplo, eles não podem usar o Windows App SDK RegisterForXXXAtivação APIs e, em vez disso, devem se registrar para ativação avançada por meio do manifesto.

Todas as restrições para aplicativos empacotados também se aplicam aos aplicativos WinUI, que são empacotados, e há considerações adicionais conforme descrito abaixo.

Considerações importantes:

• Ativação rica: GetActivatedEventArgs
  • Aplicativos não empacotados: Totalmente utilizável.
  • Aplicativos empacotados: Utilizável, mas esses aplicativos também podem usar a plataforma GetActivatedEventArgs. Observe que a plataforma define Windows.ApplicationModel.AppInstance enquanto o Windows App SDK define Microsoft.Windows.AppLifecycle.AppInstance. E enquanto os aplicativos UWP podem usar o ActivatedEventArgs aulas, como FileActivatedEventArgs e LaunchActivatedEventArgs, os aplicativos que usam o recurso Windows App SDK AppLifecycle devem usar as interfaces e não as classes (por exemplo, IFileActivatedEventArgs, ILaunchActivatedEventArgs, e assim por diante).
  • Aplicativos WinUI: App.OnLaunched do WinUI recebe um Microsoft.UI.Xaml.LaunchActivatedEventArgs, enquanto a plataforma GetActivatedEventArgs retorna um Windows.ApplicationModel.IActivatedEventArgs, e o WindowsAppSDK GetActivatedEventArgs retorna um Microsoft.Windows.AppLifecycle.AppActivationArguments objeto que pode representar uma plataforma LaunchActivatedEventArgs.
  • Para mais informações, veja Ativação avançada.
• Registrar/cancelar o registro para ativação avançada
  • Aplicativos não empacotados: Totalmente utilizável.
  • Aplicativos empacotados: Não utilizável, use o manifesto MSIX do aplicativo.
  • Para mais informações, veja Ativação avançada.
• Instância única/múltipla
  • Aplicativos não empacotados: Totalmente utilizável.
  • Aplicativos empacotados: Totalmente utilizável.
  • Aplicativos WinUI: se um aplicativo deseja detectar outras instâncias e redirecionar uma ativação, deve fazê-lo o mais cedo possível e antes de inicializar qualquer janela etc. Para habilitar isso, o aplicativo deve definir DISABLE_XAML_GENERATED_MAIN e escrever um Main (C#) ou WinMain (C++) onde ele pode fazer a detecção e o redirecionamento.
  • RedirectActivationToAsync é uma chamada assíncrona e você não deve esperar em uma chamada assíncrona se seu aplicativo estiver sendo executado em um STA. Para aplicativos Windows Forms e C# WinUI, você pode declarar Main como assíncrono, se necessário. Para aplicativos C++ WinUI e C# WPF, você não pode declarar Main como assíncrono, portanto, você precisa mover a chamada de redirecionamento para outro thread para garantir que não bloqueie o STA.
  • Para mais informações, veja Instância do aplicativo.
• Notificações de energia/estado
  • Aplicativos não empacotados: Totalmente utilizável.
  • Aplicativos empacotados: Totalmente utilizável.
  • Para mais informações, veja Gerenciamento de energia.

Problema conhecido:

• As associações de tipo de arquivo codificam incorretamente %1 como %251 ao definir o modelo de linha de comando do manipulador de verbos, que trava aplicativos Win32 descompactados. Você pode editar manualmente o valor do Registro para %1 como uma solução parcial. Se o caminho do arquivo de destino tiver um espaço, ele ainda falhará e não há solução alternativa para esse cenário.
• Esses bugs de instância única/múltipla serão corrigidos em um próximo patch de manutenção:
  • O redirecionamento de AppInstance não funciona quando compilado para x86
  • Registrar uma chave, cancelar o registro e registrá-la novamente faz com que o aplicativo falhe

WriteCore

DWriteCore é a implementação do Windows App SDK de DirectWrite, que é a API DirectX para renderização de texto de alta qualidade, fontes de contorno independentes de resolução e suporte completo a texto e layout Unicode. DWriteCore é uma forma de DirectWrite que é executada em versões do Windows até o Windows 10, versão 1809 (10.0; Build 17763) e abre a porta para você usá-lo em várias plataformas.

Funcionalidades DWriteCore contém todos os recursos do DirectWrite, com algumas exceções.

Limitações importantes

• DWriteCore não contém os seguintes recursos DirectWrite:
  • Fontes por sessão
  • Fontes de caracteres definidos pelo usuário final (EUDC)
  • APIs de streaming de fontes
• O suporte à API de renderização de baixo nível é parcial.
• DWriteCore não interopera com Direct2D, mas você pode usar IDWriteGlyphRunAnalysis e IDWriteBitmapRenderTarget.

Núcleo MRT

MRT Core é uma versão simplificada do moderno Windows Sistema de gerenciamento de recursos que é distribuído como parte do Windows App SDK.

Limitações importantes

• Em projetos .NET, os arquivos de recursos copiados e colados na pasta do projeto não são indexados em F5 se o aplicativo já tiver sido compilado. Como solução alternativa, reconstrua o aplicativo. Ver questão 1503 para mais informações.
• Em projetos .NET, quando um arquivo de recurso é adicionado ao projeto usando a interface do usuário do Visual Studio, os arquivos podem não ser indexados por padrão. Ver questão 1786 para mais informações. Para contornar esse problema, remova as entradas abaixo no arquivo CSPROJ:

  XMLCopiar

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

• Para aplicativos C++ WinUI não empacotados, o URI do recurso não foi criado corretamente. Para contornar esse problema, adicione o seguinte no vcxproj:

  XMLCopiar

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

desenvolvimento

Novos recursos e atualizações

• Você pode inicializar automaticamente o Windows App SDK por meio do WindowsPackageType project para carregar o tempo de execução do Windows App SDK e chamar as APIs do Windows App SDK. Ver Criar um aplicativo WinUI 3 para obter instruções.
• Aplicativos não empacotados podem implantar o Windows App SDK integrando-se ao Windows App SDK autônomo .exe instalador em seu MSI ou programa de instalação existente. Para mais informações, consulte Guia de implantação do Windows App SDK para aplicativos não empacotados.
• Os aplicativos .NET não empacotados também podem usar o wrapper .NET para o API de inicialização para obter dinamicamente uma dependência no pacote de estrutura do Windows App SDK em tempo de execução. Para obter mais informações sobre o wrapper .NET, consulte biblioteca de wrappers .NET.
• Os aplicativos empacotados podem usar a API de implantação para verificar e garantir que todos os pacotes necessários estejam instalados na máquina. Para obter mais informações sobre como a API de implantação funciona, consulte o guia de implantação para aplicativos empacotados.

Limitações importantes

• O wrapper .NET para a API de bootstrapper destina-se apenas ao uso por aplicativos .NET não empacotados para simplificar o acesso ao Windows App SDK.
• Somente aplicativos empacotados MSIX que são de confiança total ou têm a gerenciamento de pacotes recurso restrito tem permissão para usar a API de implantação para instalar as dependências do pacote principal e singleton. O suporte para aplicativos empacotados de confiança parcial chegará em versões posteriores.
• Ao testar F5 um aplicativo x86 que usa o DeploymentManager.Initialize método em um sistema x64, certifique-se de que a estrutura x64 seja instalada primeiro executando o WindowsAppRuntimeInstall.exe. Caso contrário, você encontrará um NÃO ENCONTRADO erro devido ao Visual Studio não implantar a estrutura x64, que normalmente ocorre por meio de implantação de armazenamento ou sideload.

Outras limitações e problemas conhecidos

• Sem suporte para qualquer configuração de compilação de CPU: Quando adicionando o SDK do aplicativo do Windows a um aplicativo ou componente .NET existente que suporte Qualquer CPU, você deve especificar a arquitetura desejada: x86, x64 or arm64.
• Atualizando do .NET 5 para o .NET 6: ao atualizar na interface do usuário do Visual Studio, você pode encontrar erros de compilação. Como solução alternativa, atualize manualmente o TargetFrameworkPackage do seu arquivo de projeto para o seguinte:

  XMLCopiar

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

• O aplicativo MSIX de projeto único C# não compila se as ferramentas UWP C++ não estiverem instaladas. Se você tiver um projeto MSIX de projeto único em C#, precisará instalar o Ferramentas universais da plataforma Windows C++ (v14x) componente opcional.
• O idioma subsequente VSIX falha ao instalar no Visual Studio 2019 quando várias versões do Visual Studio 2019 são instaladas. Se você tiver várias versões do Visual Studio 2019 instaladas (por exemplo, Release e Preview) e, em seguida, instale o Windows App SDK VSIX para C++ e C#, a segunda instalação falhará. Para resolver, desinstale as ferramentas de empacotamento MSIX de projeto único para Visual Studio 2019 após o primeiro idioma VSIX. Visualizar este feedback para obter informações adicionais sobre este problema.
• Se você quiser co_await na DispatcherQueue.TryEnqueue método, então use o currículo_primeiro plano função auxiliar no Biblioteca de Implementação do Windows (WIL):
  1. Adicione uma referência a Microsoft.Windows.ImplementationLibrary Pacote NuGet.
  2. Adicionar o #include <wil/cppwinrt_helpers.h> declaração ao seu arquivo de código.
  3. Use wil::resume_foreground(your_dispatcher); para co_await o resultado.

Leia mais e encontre os links de download em Microsoft SUA PARTICIPAÇÃO FAZ A DIFERENÇA.