Compartilhar via

Notas sobre a versão do canal estável para o SDK de Aplicativo do Windows 1.0

  • Artigo

O canal estável fornece versões do SDK do Aplicativo Windows com suporte para uso por aplicativos em ambientes de produção. Os aplicativos que usam a versão estável do SDK do Aplicativo Windows também podem ser publicados no Microsoft Store.

Links importantes:

Versão de canal estável mais recente:

Downloads para o SDK do Aplicativo Windows

Observação

As extensões do Visual Studio do SDK de Aplicativo do Windows (VSIX) não são mais distribuídas como um download separado. Elas estão disponíveis no Visual Studio Marketplace dentro do Visual Studio.

Versão 1.0.4

Essa é uma versão de manutenção do SDK do Aplicativo Windows que inclui correções importantes de bugs para a versão 1.0.

Correções de bugs (1.0.4)

  • Corrigido o problema que fazia com que o AppBars, quando usado como Page.TopAppBar ou Page.BottomAppBar, não renderizasse na tela.
  • Corrigido o problema em que aplicativos com um nome de pacote de 12 caracteres ou menos que usam um controle da WinUI de MUXControls.dll falharão imediatamente. Para obter mais informações, confira o issue n.º 6360 no GitHub.
  • Correção de problemas de entrada por toque que causaram problemas com atalhos de teclado e outros cenários. Para obter mais informações, confira o issue n.º 6291 no GitHub.
  • Corrigido o problema que fazia com que os aplicativos empacotados com MSIX ou implantados como autônomo falhassem na implantação.
  • Corrigido o problema que fazia com que os aplicativos falhassem às vezes durante uma operação de arrastar e soltar. Para obter mais informações, consulte o problema 7002 no GitHub.

Versão 1.0.3

Essa é uma versão de manutenção do SDK do Aplicativo Windows que inclui correções importantes de bugs para a versão 1.0.

Correções de bugs (1.0.3)

  • Corrigido o problema que fazia com que aplicativos C# com WebView2 falhassem na inicialização quando o CRT (Runtime do C/C++) não estava instalado.
  • Correção de problemas de entrada por toque que causaram problemas com atalhos de teclado e outros cenários. Para obter mais informações, consulte o problema 6291 no GitHub.

Observação: normalmente não adicionamos funcionalidade em uma versão de manutenção, mas a correção do WebView2 desta versão exigiu que atualizemos para a última versão do SDK do WebView2 (1020.46 a 1185.39). Consulte as Notas sobre a versão do SDK do WebView2 para obter informações adicionais sobre o WebView2 1.0.1185.39 e Distribuir seu aplicativo e o Runtime do WebView2 para obter informações adicionais sobre o Runtime do WebView2.

Versão 1.0.2

Essa é uma versão de manutenção do SDK do Aplicativo Windows que inclui correções importantes de bugs para a versão 1.0.

Correções de bugs (1.0.2)

  • Correção do problema de ciclo de layout que fazia com que um aplicativo falhasse ao rolar até o final de um ListView. Para obter mais informações, consulte o problema 6218 no GitHub.
  • Corrigido o problema que fazia com que aplicativos C# falhassem na inicialização quando o CRT (Runtime do C/C++) não estava instalado. No entanto, o CRT ainda é necessário para aplicativos C# usando o WebView2. Para obter mais informações, confira o issue n.º 2117 no GitHub.
  • Corrigido o problema em que aplicativos com MSIX de projeto único não geravam um arquivo .appinstaller. Para obter mais informações, confira o issue n.º 1821 no GitHub.
  • Corrigido o problema em que os aplicativos da WinUI não davam suporte ao .NET 6 dotnet build.

Versão 1.0.1

Essa é uma versão de manutenção do SDK do Aplicativo Windows que inclui correções importantes de bugs e suporte a várias janelas para a versão 1.0.

Correções de bugs (1.0.1)

  • Corrigido o problema que fazia com que o MddBootstrapAutoinitializer não fosse compilado com o ImplicitUsings habilitado. Para obter mais informações, confira o issue n.º 1686 no GitHub.
  • Corrigido o problema em que o foco no WebView2 seria perdido inesperadamente, causando problemas de entrada e seleção. Para obter mais informações, confira os issues n.º 5615 e n.º 5570 no GitHub.
  • Corrigido o problema que fazia com que a barra de ferramentas no aplicativo no Visual Studio não fosse clicável ao usar uma barra de título personalizada em um aplicativo WinUI 3.
  • Corrigido o problema que fazia com que o Layout do Snap não aparecesse ao usar uma barra de título personalizada em um aplicativo WinUI 3. Para obter mais informações, confira os issues n.º 6333 e n.º 6246 no GitHub.
  • Corrigido o problema que fazia com que uma exceção ao definir a propriedade Window.ExtendsContentIntoTitleBar quando Window.SetTitlebar fosse chamado com um UIElement ainda carregando.
  • Corrigido o problema em que os aplicativos MSIX de projeto único não davam suporte para dotnet build.
  • Corrigido o problema que fazia com que os aplicativos não empacotados não fossem instalados após a instalação de um aplicativo empacotado. Para obter mais informações, confira o issue n.º 1871 no GitHub.
  • Corrigido o problema de redução do desempenho durante as operações de arrastar do mouse.
  • Correção de falha ao chamar GetWindowIdFromWindow() em aplicativos não empacotados. Para obter mais informações, confira a discussão 1891 no GitHub.

As limitações e problemas conhecidos da versão 1.0 também se aplicam à versão 1.0.1.

Além disso, para aplicativos com barras de título personalizadas, fizemos alterações nesta versão (e corrigimos vários issues) que incluem correções na janela de vidro usada para operações de arrastar e soltar. A recomendação é usar os valores e comportamentos padrão (experimente!). Se a barra de título usou margens para que os botões de legenda padrão fossem interativos, recomendamos visualizar sua região de arrastar definindo a tela de fundo da barra de título como vermelha e ajustando as margens para estender a região de arrastar para os controles legenda.

Novos recursos

Estabilizamos e habilitamos a criação de várias janelas no mesmo thread em aplicativos da WinUI 3. Consulte o problema 5918 para obter mais informações.

Versão 1.0

As seções a seguir descrevem recursos novos e atualizados, limitações e problemas conhecidos para 1.0.

WinUI 3

A WinUI 3 é uma estrutura de UX (experiência do usuário) nativa para o SDK do Aplicativo Windows. Nesta versão, adicionamos vários novos recursos de SDK do Aplicativo Windows 0.8 e problemas estabilizados de versões 1.0 Versão Prévia.

Novos recursos e atualizações:

  • Adicionamos novos controles (PipsPager, Expander, BreadcrumbBar) e atualizamos os controles existentes para refletir os estilos mais recentes do Windows da WinUI 2.6.
  • O empacotamento MSIX de projeto único tem suporte na WinUI criando um novo aplicativo usando o modelo "Aplicativo em Branco, Empacotado...".
  • Agora, damos suporte à implantação de aplicativos WinUI 3 que não são empacotados nas versões 1809 e superiores do Windows. Confira Criar seu primeiro projeto da WinUI 3 (SDK de Aplicativo do Windows) para obter informações adicionais.
  • Os projetos da WinUI 3 agora podem definir sua versão de destino como Windows 10, versão 1809. Anteriormente, eles só podiam ser definidos a partir da versão 1903.
  • Na barra de ferramentas do aplicativo, Recarga Dinâmica e Live Visual Tree para aplicativos empacotados WinUI têm suporte no Visual Studio 2022 Preview 5 e GA.

Limitações importantes:

  • Problemas conhecidos para aplicativos da WinUI empacotados e não empacotados:

    • Erro em tempo de execução em aplicativos C++ ou C# que fazem referência a um componente do Windows Runtime C++:

      • Para resolver, adicione o destino abaixo ao final do .vcxproj do componente do Windows Runtime:
      <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>
      • O erro esperado será semelhante ao erro de origem do WinRT - 0x80004005: 'Não é possível localizar o recurso de 'ms-appx:///BlankPage.xaml'.'.

  • Problemas conhecidos para aplicativos da WinUI com MSIX de projeto único (aplicativo em Branco, modelo Empacotado):

    • Pacote ausente Publicar item de menu até reiniciar o Visual Studio: ao criar um novo aplicativo com MSIX de projeto único no Visual Studio 2019 e 2022 usando o modelo de projeto de aplicativo em branco, empacotado (WinUI 3 na Área de Trabalho), o comando para publicar o projeto não aparece no menu até que você feche e abra novamente o Visual Studio.
    • Um aplicativo C# com MSIX de projeto único não será compilado sem o componente opcional "Ferramentas C++ (v14x) da Plataforma Universal do Windows" instalado. Confira Instalar ferramentas para o SDK do Aplicativo Windows para obter mais informações.
    • Possível erro de runtime em um aplicativo com MSIX de projeto único que consome tipos definidos em um componente de Windows Runtime referenciado: para resolve, adicione manualmente entradas de classe ativáveis ao 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 da WinUI 3 que não são empacotados (aplicativos não empacotados):

  • Problemas conhecidos para empacotar e implantar aplicativos da WinUI:

    • Não há suporte para o comando Package em aplicativos da WinUI com MSIX de projeto único (aplicativo em Branco, modelo Empacotado). Em vez disso, use o comando Package & Publish para criar um pacote MSIX.
    • Para criar um pacote NuGet a partir de uma Biblioteca de Classes C# com o comando Pack, verifique se o ativo Configuration é Release.
    • Não há suporte para o comando Pack em Componentes de C++ do Windows Runtime para criar um pacote NuGet.

Para obter mais informações ou para começar a desenvolver com o WinUI, confira:

Windowing

O SDK do Aplicativo Windows fornece uma classe AppWindow que desenvolve a classe prévia Windows.UI.WindowManagement.AppWindow anterior e a disponibiliza para todos os aplicativos do Windows, incluindo Win32, WPF e WinForms.

Novos recursos:

  • AppWindow é 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. Esse é o contêiner no qual o 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 o Win32, o AppWindow pode ser visto como uma abstração de alto nível do HWND.
  • DisplayArea representa uma abstração de alto nível de um HMONITOR, segue os mesmos princípios que o AppWindow.
  • DisplayAreaWatcher permite que um desenvolvedor observe as alterações na topologia de exibição e enumere as DisplayAreas definidas atualmente no sistema.

Para obter mais informações, confira Gerenciar janelas de aplicativos (SDK de Aplicativo do Windows).

Entrada

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

Novos recursos:

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

Limitações importantes:

  • Todas as funções de fábrica estáticas do PointerPoint foram removidas: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints e GetIntermediatePointsTransformed.
  • O SDK do Aplicativo Windows não dá suporte à recuperação de objetos PointerPoint com IDs de ponteiro. Em vez disso, use a função membro PointerPointGetTransformedPoint para recuperar uma versão transformada de um objeto PointerPoint existente. Para pontos intermediários, use as funções membro PointerEventArgsGetIntermediatePoints e GetTransformedIntermediatePoints.
  • O uso direto da API do SDK da plataforma Windows.UI.Core.CoreDragOperation não funcionará com os aplicativos da WinUI.
  • As propriedades PointerPoint, RawPosition e ContactRectRaw foram removidas porque se referiam a valores não previstos, que eram os mesmos que os valores normais no sistema operacional. Em vez disso, use a Posição e o ContactRect. A previsão de ponteiro agora é tratada com o objeto da API do Microsoft.UI.Input.PointerPredictor.

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 Windows para uso por tipos de aplicativo da área de trabalho, especialmente aplicativos de Console não empacotados, aplicativos Win32, aplicativos Windows Forms e aplicativos WPF. A implementação de SDK do Aplicativo Windows desses recursos não pode ser usada em aplicativos UWP, pois há recursos equivalentes na própria plataforma UWP.

Importante

Se você estiver trabalhando em um aplicativo UWP, veja Migrar da UWP para o SDK do Aplicativo Windows.

Aplicativos que não sejam da UWP também podem ser empacotados em pacotes MSIX. Embora esses aplicativos possam usar alguns dos recursos do ciclo de vida do SDK do Aplicativo Windows, eles devem usar a abordagem de manifesto em que isso está disponível. Por exemplo, eles não podem usar as APIs de RegisterForXXXActivation do SDK do Aplicativo Windows e devem registrar-se para ativação avançada por meio do manifesto.

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

Considerações importantes:

  • Ativação avançada: GetActivatedEventArgs

  • Registrar/cancelar o registro para ativação avançada

  • Instanciação única/múltipla

    • Aplicativos não empacotados: totalmente utilizáveis.
    • Aplicativos empacotados: totalmente utilizáveis.
    • Aplicativos da WinUI: se um aplicativo quiser detectar outras instâncias e redirecionar uma ativação, ele deverá fazer isso o mais cedo possível e antes de inicializar qualquer janela etc. Para habilitar isso, o aplicativo deve definir DISABLE_XAML_GENERATED_MAIN e gravar um Main (C#) ou WinMain (C++) personalizado, em que 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 o aplicativo estiver em execução em um STA. Para aplicativos da WinUI do Windows Forms e C#, declare Main como assíncrono, se necessário. Para aplicativos da WinUI C++ e WPF C#, não é possível declarar Main como assíncrono, portanto, em vez disso, mova a chamada de redirecionamento para outro thread para garantir que você não bloqueie o STA.
    • Para obter mais informações, confira Instanciação de aplicativo com a API de ciclo de vida do aplicativo.

  • Notificações de energia/estado

Problema conhecido:

  • As associações de Tipo de Arquivo codificam incorretamente %1 como %251 ao definir o modelo de linha de comando do manipulador do Verbo, que falha em aplicativos do Win32 não empacotados. Edite manualmente o valor do Registro para ser %1 como uma solução alternativa parcial. Se o caminho do arquivo de destino tiver um espaço, ele ainda falhará e não haverá 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 appInstance não funciona quando compilado para x86
    • Registrar uma chave, cancelá-la e registrá-la novamente faz com que o aplicativo falhe

DWriteCore

O DWriteCore é a implementação de SDK do Aplicativo Windows de DirectWrite, que é a API do DirectX para renderização de texto de alta qualidade, fontes de estrutura de tópicos independentes de resolução e suporte completo de texto e layout Unicode. O DWriteCore é um tipo de DirectWrite que é executado em versões do Windows até o Windows 10 versão 1809 (10.0; Build 17763), e permite o uso em multiplataforma.

Recursos:

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

Limitações importantes:

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

Para obter mais informações, confira Visão geral do DWriteCore.

MRT Core

O MRT Core é uma versão simplificada do Sistema de Gerenciamento de Recursos do Windows moderno que é distribuído como parte do SDK do Aplicativo Windows.

Limitações importantes:

  • Em projetos do .NET, os arquivos de recurso copiados colados na pasta do projeto não serão indexados em F5 se o aplicativo já tiver sido criado. Como solução alternativa, recompile o aplicativo. Consulte o problema 1503 para obter mais informações.

  • Em projetos do .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. Consulte o problema 1786 para obter mais informações. Para contornar esse problema, remova as entradas abaixo no arquivo CSPROJ:

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

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

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

<PropertyGroup>
    <AppxPriInitialPath></AppxPriInitialPath>   
</PropertyGroup>

Para obter mais informações, consulte Gerenciar recursos com o MRT Core.

Implantação

Novos recursos e atualizações:

Limitações importantes:

  • O empacotador do .NET para a API Bootstrapper destina-se apenas ao uso por aplicativos do .NET não empacotados para simplificar o acesso ao SDK do Aplicativo Windows.
  • Somente aplicativos em pacote MSIX que são de confiança total ou têm a funcionalidade restrita packageManagement têm a permissão para usar a API de implantação para instalar as dependências do pacote Main e Singleton. O suporte para aplicativos empacotados de confiança parcial será disponibilizado em versões posteriores.
  • Ao testar F5 um aplicativo x86 que usa o método DeploymentManager.Initialize em um sistema x64, verifique se a estrutura x64 é instalada pela primeira vez executando o WindowsAppRuntimeInstall.exe. Caso contrário, você encontrará um erro de NOT_FOUND devido ao Visual Studio não implantar a estrutura x64, que normalmente ocorre por meio da implantação da Store ou do sideload.

Outras limitações e problemas conhecidos

  • Sem suporte para qualquer configuração de build de CPU: ao adicionar o SDK do Aplicativo Windows a um aplicativo ou componente do .NET existente que dê suporte a Qualquer CPU, especifique a arquitetura desejada: x86, x64 ou arm64.

  • Atualizar do .NET 5 para o .NET 6: ao atualizar na interface do usuário do Visual Studio, é possível encontrar erros de build. Como solução alternativa, atualize manualmente o arquivo de projeto TargetFrameworkPackage para o seguinte:

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

  • O aplicativo MSIX de projeto único em C# não será compilado se as Ferramentas UWP do C++ não estiverem instaladas. Se você tiver um projeto MSIX de projeto único em C#, precisará instalar o componente opcional Ferramentas C++ (v14x) da Plataforma Universal do Windows.

  • O VSIX de linguagem subsequente não é instalado no Visual Studio 2019 quando várias versões do Visual Studio 2019 são instaladas. Caso tenha várias versões do Visual Studio 2019 instaladas (por exemplo, Versão e Versão Prévia) e, em seguida, instalar o VSIX do SDK do Aplicativo Windows para C++ e C#, a segunda instalação falhará. Para resolver, desinstale as Ferramentas de Empacotamento MSIX de projeto único para o Visual Studio 2019 após o primeiro VSIX de idioma. Exiba este comentário para obter informações adicionais sobre esse problema.

  • Uma alternativa ao DispatcherQueue.TryEnqueue (para retomar a execução no thread da fila do dispatcher) é usar a função auxiliar resume_foreground na WIL (Biblioteca de Implementação do Windows):

    1. Adicione uma referência ao seu projeto ao pacote NuGet Microsoft.Windows.ImplementationLibrary.
    2. Adicione #include <wil/cppwinrt_helpers.h> ao seu pch.h.
    3. Adicione #include <winrt/Microsoft.UI.Dispatching.h> ao seu pch.h.
    4. Agora co_await wil::resume_foreground(your_dispatcherqueue);.