Perguntas Frequentes sobre o Desenvolvimento de Aplicativos para Windows

Essas perguntas frequentes fornecem respostas para perguntas comuns sobre Windows desenvolvimento de aplicativos, incluindo diretrizes sobre como escolher a estrutura certa para seus projetos. Os tópicos abordados incluem:

  • Introdução e o cenário de desenvolvimento de aplicativos Windows.
  • Desenvolvimento de aplicativos nativos somente Windows com WinUI 3, Windows Presentation Foundation (WPF) e Windows Forms (WinForms).
  • Windows SDK (Software Development Kit) e SDK do Aplicativo Windows.
  • Focar no Windows como parte de sua estratégia de desenvolvimento multiplataforma.
  • Desenvolvimento de aplicativos Web e híbridos com .NET MAUI, Blazor e ASP.NET Core.
  • Como escolher uma abordagem ao entender os investimentos da Microsoft.

Cenário de desenvolvimento de aplicativos para Windows

Em lugares em que posso encontrar uma visão geral simples das tecnologias de desenvolvimento Windows?

Para obter uma visão geral das opções de hoje para desenvolvedores Windows, assista ao episódio Windows Dev Chat escolhendo sua plataforma de desenvolvimento ideal, que discute WinUI 3, .NET MAUI, React Native, Blazor e PROGRESSIVE Aplicativos Web (PWAs). Você pode encontrar outros episódios na playlist do Windows Dev Chat.

Você também pode consultar o overview das opções de desenvolvimento de aplicativos para desenvolvedores Windows.

Por que o desenvolvimento de aplicativos cliente ainda é crucial para a transformação digital moderna na era do cloud services?

Na era dos serviços de nuvem, o desenvolvimento de aplicativos cliente continua sendo importante para fornecer interações responsivas e significativas em dispositivos de usuário.

Veja por que os aplicativos cliente importam:

  • Alcance do dispositivo: Os aplicativos cliente permitem que você traga seu aplicativo diretamente aos usuários em seus dispositivos de escolha.
  • Gateway para Serviços Inteligentes: aplicativos de cliente geralmente são a primeira interação que os usuários têm com os seus serviços. Eles oferecem uma interface avançada e interativa que permite que você mostre recursos inteligentes e diferencie seu produto de outras pessoas.
  • Escalabilidade com Integração na Nuvem: Um aplicativo cliente bem integrado pode sincronizar sem esforço com serviços de back-end na nuvem, permitindo acesso a dados em tempo real e escalabilidade sem interrupções à medida que sua base de usuários cresce.
  • Produtividade Aprimorada e Fidelidade do Usuário: Um aplicativo cuidadosamente projetado pode aumentar a produtividade e manter os usuários envolvidos com seu produto ou serviço ao longo do tempo.

Desenvolvimento de aplicativos nativos somente para Windows

O que é o SDK do Aplicativo Windows?

O SDK do Aplicativo Windows fornece componentes com manutenção independente para aplicativos da área de trabalho do Windows, incluindo WinUI 3, ciclo de vida do aplicativo, gerenciamento de janelas, notificações, recursos e APIs de texto. Ele dá suporte a aplicativos executados em Windows 10, versão 1809 e posterior, sujeitos ao ciclo de vida de suporte da versão Windows e SDK do Aplicativo Windows versão.

O que é a diferença entre o SDK do Aplicativo Windows e o SDK do Windows?

Ambos são SDKs (kits de desenvolvimento de software) que permitem criar Windows aplicativos.

O SDK do Aplicativo Windows fornece componentes que são enviados independentemente de Windows e funcionam em versões de Windows com suporte até Windows 10, versão 1809. Ele inclui WinUI 3 e APIs para ciclo de vida do aplicativo, janelas, notificações, recursos, texto e outros recursos.

O SDK do Windows fornece cabeçalhos, bibliotecas, metadados e ferramentas para APIs do sistema operacional, como Win32, WinRT, COM, DirectX, dispositivos e recursos de shell.

O SDK do Aplicativo Windows não substitui o SDK do Windows. Os aplicativos que adotam o SDK do Aplicativo Windows podem continuar a usar APIs do SDK Windows e os aplicativos WinUI 3 geralmente usam ambos.

Estou criando uma nova equipe para desenvolver um aplicativo somente Windows. Por que devo optar por desenvolver com uma estrutura de Windows nativa, como WinUI 3, WPF ou WinForms?

Aqui estão alguns motivos para escolher uma estrutura de Windows nativa para seu aplicativo somente Windows:

  • as estruturas Performance: Native Windows são otimizadas para aproveitar o hardware Windows moderno, fornecendo experiências rápidas e responsivas do usuário.
  • Integration: Windows é fornecido com uma ampla variedade de APIs que permitem experiências sofisticadas disponíveis apenas em Windows. As estruturas nativas fornecem integração profunda com esses recursos e APIs.
  • Experiência do usuário nativa: frameworks nativos fornecem uma experiência consistente entre dispositivos Windows, garantindo que seu aplicativo tenha uma aparência e um bom funcionamento em qualquer lugar.
  • Suporte offline: As estruturas nativas dão suporte a cenários offline, permitindo que os aplicativos funcionem mesmo sem conectividade com a Internet.
  • Suporte e ferramentas: Microsoft mantém as estruturas nativas e fornece SDKs atuais, documentação, ferramentas de depuração e exemplos.
Porque estrutura devo usar para aproveitar os investimentos mais recentes da Microsoft no desenvolvimento de aplicativos Windows?

Se você estiver criando um novo aplicativo de área de trabalho Windows de uso geral, recomendamos usar o WinUI 3. O WinUI 3 é a estrutura de interface do usuário nativa fornecida com o SDK do Aplicativo Windows. Ele dá suporte a aplicativos da área de trabalho do Windows e fornece acesso aos controles atuais do Fluent e aos recursos da plataforma Windows.

Posso usar SDK do Aplicativo Windows/WinUI 3 no meu aplicativo de Windows existente?

Observe que o WinUI 3 (uma estrutura de interface do usuário) é fornecido com o SDK do Aplicativo Windows (uma estrutura de desenvolvimento de plataforma Windows).

Você pode migrar a interface do usuário de um aplicativo para o WinUI 3 ou usar o WinUI XAML Islands para hospedar controles SDK do Aplicativo Windows em um host de área de trabalho existente com suporte. Os XAML Islands de sistemas legados hospedam controles XAML UWP e usam APIs diferentes.

Elementos do SDK do Aplicativo Windows geralmente podem ser usados em aplicativos da área de trabalho, dependendo de como o aplicativo existente foi criado. Aplicativos UWP não são suportados pelo SDK do Aplicativo Windows.

Isso significa que aplicativos WPF/MFC/WinForms podem usar APIs SDK do Aplicativo Windows que não estão relacionadas ao WinUI 3. Exemplos incluem ciclo de vida do aplicativo, janelas e notificações de aplicativo.

Consulte Use o SDK do Aplicativo Windows em um projeto existente para obter mais informações.

Preciso usar Visual Studio para criar aplicativos WinUI 3?

Não. Os builds XAML do WinUI 3 usam o MSBuild, mas você pode criar com o SDK .NET e os modelos atuais do WinUI 3 da linha de comando em outro editor. Consulte o início rápido da linha de comando.

Visual Studio 2026 fornece a mais rica experiência de edição integrada, depuração, criação de perfil e XAML Recarga Dinâmica. Use o fluxo de trabalho que corresponde aos seus requisitos de ferramentas.

Eu obtém um erro "Não é possível carregar a DLL 'Microsoft.ui.xaml.dll'" ao executar meu aplicativo. Como corrigi-lo?

Esse erro geralmente ocorre em cenários de aplicativo unpackaged em que o runtime SDK do Aplicativo Windows não foi instalado no computador. Experimente o seguinte:

  • Se você estiver executando um aplicativo packaged (o padrão recomendado), verifique se você está iniciando via Visual Studio com o perfil de inicialização MsixPackage selecionado (não o perfil executável sem formatação). A etapa de empacotamento MSIX instala os componentes de runtime necessários.
  • Se você estiver executando um aplicativo não empacotado dependente da estrutura, instale o runtime correspondente do SDK do Aplicativo Windows. Uma implantação autocontida inclui as dependências do SDK do Aplicativo Windows.
  • Confirme se o projeto corresponde ao modelo de implantação. Para um aplicativo .NET normal não empacotado, definir <WindowsPackageType>None</WindowsPackageType> permite a inicialização automática do runtime do SDK do Aplicativo Windows. Use a API do bootstrapper diretamente somente quando precisar de controle explícito sobre a inicialização de dependência dinâmica.

Consulte Implantar aplicativos que usam o SDK do Aplicativo Windows para obter mais detalhes sobre os requisitos de implantação.

Qual é a diferença entre WinUI 3 e WinUI 2 para UWP?

O WinUI 3 é a estrutura de interface do usuário nativa atual do Microsoft para aplicativos da área de trabalho Windows e é entregue como parte do SDK do Aplicativo Windows.

O WinUI 2, também chamado de WinUI para UWP, é uma biblioteca de controles e estilos para aplicativos UWP. WinUI 2 e WinUI 3 usam namespaces XAML diferentes e não são compatíveis com binários.

Quando eu compilo um aplicativo usando SDK do Aplicativo Windows e WinUI 3, estou criando um "aplicativo WinUI"?

Sim. O aplicativo WinUI 3 é o termo mais claro para um aplicativo cuja interface do usuário usa WinUI 3 e o SDK do Aplicativo Windows. Aplicativo WinUI também é usado com frequência quando o contexto é inequívoco.

Posso atualizar incrementalmente meu aplicativo UWP com WinUI para controles UWP para WinUI 3 substituindo gradualmente os controles?

Não. SDK do Aplicativo Windows não pode ser usado em aplicativos UWP e o WinUI para UWP não pode ser misturado com o WinUI 3. Consulte Migrate da UWP para o SDK do Aplicativo Windows.

Qual é a dificuldade de migrar um aplicativo UWP para o WinUI 3?

UWP e WinUI 3 compartilham muitos conceitos XAML, mas a migração não é uma alteração direta do namespace. O custo depende principalmente de:

  1. Arquivo do projeto e personalização do MSBuild: O esforço de migração varia dependendo do uso avançado do MSBuild.
  2. Migração da API do .NET: aplicativos UWP que usam .NET Native podem migrar para uma versão do .NET com suporte atual com Native AOT. Essa modernização é separada da migração da interface do usuário para o WinUI 3.
  3. Bibliotecas de componentes da interface do usuário: As bibliotecas devem ter versões direcionadas ao WinUI 3.
  4. APIs de janelas e modelo de aplicativo: As APIs UWP vinculadas a conceitos como CoreWindow, ApplicationView ou GetForCurrentView exigem substituições do SDK do Aplicativo Windows ou outra abordagem para desktop.
  5. Projeção de linguagem C++: Se o aplicativo UWP usar a projeção C++/CX substituída, portar esse código para C++/WinRT.

Para obter mais informações, consulte Migrar da UWP para o SDK do Aplicativo Windows e o mapeamento de API da UWP para o SDK do Aplicativo Windows.

Se eu tiver um aplicativo UWP existente na Loja, posso publicar um novo aplicativo WinUI 3 empacotado usando os mesmos identificadores?

Sim, os aplicativos atualizados podem ser publicados sem atualizar a identidade do aplicativo. Os usuários da versão antiga serão atualizados para a nova versão. Isso se aplica somente a aplicativos de desktop. Xbox, HoloLens e aplicativos padrão do Hub Surface não podem migrar para o WinUI 3.

Como fazer para empacotar ou distribuir meu aplicativo WinUI 3?

Confira a visão geral de empacotamento e implantação.

Onde posso encontrar as diretrizes de migração do SDK do Aplicativo Windows?

Consulte Migrate da UWP para o SDK do Aplicativo Windows.

Preciso usar a marcação XAML se quiser usar o WinUI 3?

Não. Os controles de interface do usuário podem ser criados no código. No entanto, representar a interface do usuário na marcação XAML declarativa oferece muitos benefícios, incluindo uma experiência de desenvolvedor aprimorada.

  • Migrando da UWP para o WinUI 3: muitos conceitos de XAML e interface do usuário são transferidos, mas os namespaces, o modelo de projeto e algumas APIs diferem.
  • Migrando de WPF para o WinUI 3: muitos conceitos são transferidos, mas o conjunto de controles e as APIs diferem.
O Visual Studio tem uma superfície de design ou um designer de interface do usuário para WinUI 3?

No momento, não. Use Recarga Dinâmica XAML, Live Visual Tree, Live Property Explorer e ferramentas de runtime relacionadas para inspecionar e atualizar o XAML enquanto o aplicativo é executado.

Para obter um passo a passo completo das ferramentas de design de runtime disponíveis para WinUI 3, consulte as ferramentas de design de runtime XAML para WinUI 3.

O SDK do Aplicativo Windows inclui o WinUI 3?

Sim. WinUI 3 é fornecida como parte do SDK do Aplicativo Windows.

O SDK do Aplicativo Windows inclui WinUI para UWP?

Não. O WinUI para UWP faz parte da plataforma UWP.

O WinUI para UWP e WinUI 3 é criado com base na mesma tecnologia?

Não exatamente. Embora o WinUI 3 tenha iniciado a partir da base de código do WinUI para UWP, elas são tecnologias distintas. Ambas são estruturas de interface do usuário baseadas em XAML que funcionam entre .NET e C++, mas o WinUI para UWP e WinUI 3 não são compatíveis entre si.

Posso usar o WinUI 3 sem usar SDK do Aplicativo Windows?

Não. WinUI 3 é fornecida como parte do SDK do Aplicativo Windows.

Posso usar o WinUI 3 em um aplicativo não empacotado?

Sim. O WinUI 3 e muitas APIs SDK do Aplicativo Windows funcionam em aplicativos não empacotados. No entanto, alguns recursos do Windows exigem uma identidade de pacote, e os aplicativos não empacotados dependentes de framework devem inicializar o runtime do SDK do Aplicativo Windows. Compare as opções em Visão geral do empacotamento e Recursos que exigem identidade de pacote.

Qual é a diferença entre ilhas XAML e WinUI 3?

O WinUI 3 é a estrutura de interface do usuário incluída no SDK do Aplicativo Windows. XAML Islands são uma técnica de hospedagem que permite que um aplicativo de desktop existente insira conteúdo XAML ao lado da interface do usuário de outro framework.

O termo pode se referir a ilhas XAML legadas do sistema que hospedam controles XAML do UWP ou a ilhas XAML do WinUI que hospedam controles do SDK do Aplicativo Windows em hosts de desktop com suporte. As APIs, os namespaces e os requisitos de host diferem.

Se eu criar um aplicativo WinUI 3, ele ficará moderno em Windows 11 e Windows 10?

Os controles WinUI 3 usam o estilo Fluent em versões compatíveis de Windows 10 e Windows 11, em aplicativos empacotados e não empacotados. Alguns efeitos e comportamentos do sistema operacional diferem por Windows versão. Por exemplo, Mica está disponível no Windows 11 e volta para uma cor sólida no Windows 10.

Posso usar planos de fundo Mica ou Acrílico em aplicativos criados com SDK do Aplicativo Windows?

Sim. O Acrílico da Área de Trabalho tem suporte no Windows 10, versão 1809 e posterior. Mica requer Windows 11 e volta para uma cor de tema sólida no Windows 10. Chame MicaController.IsSupported ou DesktopAcrylicController.IsSupported em tempo de execução antes de aplicar um pano de fundo. Consulte Aplicar Mica ou Materiais Acrílicos em Aplicativos de Desktop para Windows 11.

Onde posso encontrar exemplos do WinUI 3?

Consulte Exemplo e recursos. Alguns repositórios de destaque:

Se eu já tiver investido pesado em WPF, devo continuar a usar WPF ou considerar migrar para o WinUI 3?

Se você já investiu pesado em WPF, pode continuar usando-o para aplicativos existentes. WPF é uma estrutura madura e estável amplamente usada para criar Windows aplicativos da área de trabalho.

Use GitHub Copilot Upgrade para avaliar e migrar um aplicativo WPF do .NET Framework para o .NET moderno. Examine o plano gerado e valide cada alteração em seu aplicativo.

Se eu criar um novo aplicativo WPF, ele parecerá datado em comparação com outros novos aplicativos Windows?

Ao desenvolver um aplicativo WPF com .NET 9 ou posterior, você pode garantir que seu aplicativo corresponda à aparência elegante e moderna de Windows 11. O novo tema fluente para WPF apresenta uma estética Windows 11 contemporânea, com suporte integrado ao modo Claro/Escuro e à cor de destaque do sistema. Isso moderniza a aparência do aplicativo e oferece uma experiência de usuário polida e coesa.

Minha equipe está confortável criando aplicativos WinForms e atende às nossas necessidades. Devemos considerar a migração para o WinUI 3 ou outra estrutura?

Se o WinForms atender às suas necessidades e sua equipe estiver confortável com isso, você poderá continuar usando WinForms para aplicativos existentes. A estrutura WinForms é madura e estável, amplamente usada para o desenvolvimento de aplicativos de desktop para Windows.

A equipe do WinForms continua investindo na plataforma. O trabalho recente e contínuo inclui:

  • APIs assíncronas de formulário e diálogo
  • Suporte ao modo escuro e a estilos visuais
  • Acessibilidade, alta DPI, layout e melhorias de designer
  • Área de transferência e modernização DataObject

Desenvolvimento nativo multiplataforma

Quais são alguns motivos para criar aplicativos nativos, que funcionam em várias plataformas, direcionados para Windows?

Se você estiver direcionando usuários em várias plataformas de sistema operacional, a criação de aplicativos multiplataforma com .NET MAUI ou React Native pode oferecer vários benefícios:

  • Chegar: Os aplicativos multiplataforma atingem um público-alvo maior em diferentes dispositivos e sistemas operacionais.
  • Reutilização de código: Reutilização de código entre plataformas reduz o tempo e o custo de desenvolvimento. Criar aplicativos separados para Windows, Android, iOS e macOS pode ser proibitivamente caro.
  • Experiência consistente do usuário: As estruturas multiplataforma ajudam a fornecer uma aparência consistente entre plataformas.
  • Integração: Aplicativos multiplataforma ainda podem se integrar a serviços específicos da plataforma para oferecer uma experiência abrangente.
Não posso ter certeza de que .NET MAUI aplicativos serão executados bem em Windows?

Quando você cria um aplicativo .NET MAUI para Windows, a saída usa WinUI 3. Durante o desenvolvimento, o .NET MAUI oferece uma única experiência de .NET por meio de plataformas, mas gera código específico da plataforma nos bastidores.

Como o .NET MAUI pode fornecer APIs de dispositivo nativo em cada plataforma?

.NET MAUI fornece uma experiência de .NET unificada em Windows, iOS, Android e macOS. Ele oferece APIs multiplataforma para recursos comuns, como armazenamento, rede e sensores de dispositivo. Você também pode chamar APIs específicas da plataforma ou fornecer implementações especializadas para cada plataforma.

Posso começar com o WinUI 3 e, posteriormente, integrar .NET MAUI se eu eventualmente quiser direcionar cenários de plataforma cruzada?

Não neste momento. Embora .NET MAUI use o WinUI 3 ao executar em Windows, as equipes que esperam direcionar várias plataformas devem começar com .NET MAUI ou React Native for Desktop.

Nossa equipe tem fortes habilidades de desenvolvimento de front-end na Web. Devemos considerar o uso do React Native para Área de Trabalho?

Equipes com forte experiência de desenvolvimento na Web podem querer considerar o React Native para Área de Trabalho. Ele inclui o React Native para Windows e macOS. Com a abordagem "Aprender uma vez, escrever em qualquer lugar", as habilidades existentes de JavaScript, TypeScript e React podem ser usadas para criar aplicativos nativos de Windows e macOS.

O React Native for Desktop renderiza a interface do usuário diretamente para primitivos nativos, fornecendo recursos nativos de desempenho e plataforma.

Consulte a documentação React Native for Desktop para começar.

Há algum outro dispositivo Windows com suporte do React Native for Desktop?

O React Native para Windows dá suporte às versões de Windows listadas em sua documentação de compatibilidade. Verifique a compatibilidade com as famílias de dispositivos da versão do React Native para Windows que você pretende usar, em vez de presumir que todos os dispositivos Windows são compatíveis.

O que devo usar se quiser criar aplicativos que funcionam em Windows e Xbox?

Para um aplicativo do Xbox, use UWP e leve em consideração as limitações específicas do Xbox para UWP. Para desenvolvimento de jogos, use o kit de desenvolvimento de jogos da Microsoft.

O que devo usar se quiser criar aplicativos que funcionam no hub Windows e Surface?

Para um Hub Surface que executa as Salas do Teams padrão ou o ambiente do Hub Surface, use um aplicativo UWP que atenda aos requisitos de aplicativo do Hub Surface. Um Surface Hub 3 configurado com Windows 11 Pro ou Enterprise pode executar tecnologias de aplicativo da área de trabalho com suporte, portanto, a UWP não é a única opção nessa configuração.

Desenvolvimento híbrido e web

O que são aplicativos híbridos e por que devo considerar a criação de um?

Os aplicativos híbridos combinam o melhor do desenvolvimento de aplicativos web e nativos. Seu núcleo é criado usando tecnologias web como HTML, CSS e JavaScript e encapsulado em um contêiner nativo que fornece access a determinados recursos e hardware de plataforma nativa. Eles também podem ser distribuídos por meio de lojas de aplicativos.

A principal vantagem é que os aplicativos híbridos permitem que você crie um único aplicativo que possa ser executado em várias plataformas nativas e na Web, reduzindo o tempo e o custo de desenvolvimento. Exemplos de plataformas de desenvolvimento de aplicativos híbridos incluem:

  • Electron para aplicativos da área de trabalho
  • Ionic para aplicativos móveis
  • .NET MAUI Blazor Hybrid para aplicativos multiplataforma
Como eu posso criar aplicativos web progressivos (PWAs) com aparência nativa no Windows?

Consulte Desenvolvimento Web no Windows e Visão geral dos Aplicativos Web Progressivos.

O que é um aplicativo híbrido .NET MAUI Blazor?

Com .NET MAUI, os aplicativos Blazor podem ser executados nativamente em Windows, iOS, Android e macOS. Isso permite que você crie aplicativos cliente híbridos que combinam o Blazor e .NET MAUI componentes em um único aplicativo cliente nativo, com acesso total aos recursos de plataforma nativa.

Saiba mais em ASP.NET Core Blazor Hybrid.

Os componentes web de um aplicativo híbrido .NET MAUI precisam ser criados com Blazor?

Não. A partir do .NET 9, .NET MAUI inclui um controle HybridWebView que permite hospedar outras interfaces do usuário baseadas em JavaScript dentro de um aplicativo nativo.

Isso permite hospedar aplicativos Angular, React, Vue ou outros aplicativos HTML/JavaScript dentro de um aplicativo .NET MAUI. O controle híbrido fornece interoperabilidade entre C# e JavaScript, de modo que o código C# pode chamar funções JavaScript e vice-versa.

Algum outro tipo de aplicativo nativo pode hospedar componentes híbridos Blazor?

Sim. O WPF e os aplicativos WinForms também podem hospedar componentes híbridos Blazor, permitindo a adição de moderna interface do usuário da Web a aplicativos existentes. Não há suporte para aplicativos WPF ou WinForms criados no .NET Framework.

Meu aplicativo inteiro precisa ser um aplicativo híbrido ou posso misturar componentes nativos e híbridos?

Componentes nativos e híbridos podem ser misturados em um aplicativo. Por exemplo, o núcleo de um aplicativo pode ser criado com componentes .NET MAUI enquanto os componentes híbridos fornecem funcionalidade adicional. Isso permite combinar o desempenho e os recursos de componentes nativos com a flexibilidade e a eficiência de custo dos componentes híbridos.

O que são minhas opções para criar aplicativos Web baseados em .NET que ficam ótimos em navegadores modernos no Windows?

Web apps oferecem o maior alcance de qualquer plataforma de aplicativo cliente. As opções para criar belos aplicativos Web .NET incluem:

  • Aplicativos ASP.NET Core com Razor Pages
  • Aplicativos ASP.NET Core MVC
  • Aplicativos ASP.NET Core Blazor, com opções de modelos de hospedagem:
    • WebAssembly Blazor
    • Blazor Server

Os modelos de hospedagem blazor agora podem ser configurados no nível do componente, permitindo cenários como hospedar um componente Blazor WebAssembly em um aplicativo Blazor Server.

Consulte a documentação ASP.NET Core para obter mais detalhes.

Escolha uma abordagem e entenda os investimentos da Microsoft

Há tantas opções de frameworks para criar aplicativos voltados para Windows! Como faço para decidir?

Windows é uma plataforma aberta que dá suporte a muitas tecnologias. Aqui estão alguns critérios que podem ajudá-lo a escolher uma plataforma:

  • Você está desenvolvendo primeiramente para Windows ou para várias plataformas?
  • Quais idiomas ou habilidades você já tem : .NET, JavaScript, outra coisa?
  • Você precisa de acesso a APIs específicas de Windows?
  • Quais recursos da estrutura melhor correspondem aos requisitos do seu aplicativo?
  • Consulte esta tabela para obter fatores de comparação adicionais.

Para muitos aplicativos de negócios, as equipes geralmente escolhem com base nas habilidades existentes e no que a equipe está mais confortável usando.

Como eu escolho a melhor abordagem de desenvolvimento para meu aplicativo web?

Considere o seguinte ao escolher uma abordagem de desenvolvimento para seu aplicativo Web:

  • O Blazor é recomendado para criar aplicativos Web front-end com .NET. Ele permite que você crie o front-end e o back-end usando .NET, economizando tempo e custo, e isso é especialmente bom para aplicativos empresariais.
  • Os web apps JavaScript ainda fazem sentido se você quiser aproveitar as habilidades existentes do JavaScript ou precisar se integrar a bibliotecas ou estruturas JS estabelecidas.
  • Os aplicativos existentes que usam estruturas mais antigas, como Web Forms, MVC ou Razor Pages, permanecem com suporte e podem continuar a ser desenvolvidos e mantidos.
Quem está criando aplicativos com o WinUI 3 hoje?

Microsoft Fotos é um exemplo documentado. O aplicativo migrou da UWP para o SDK do Aplicativo Windows e continua a usar o WinUI 3. Para obter detalhes sobre a arquitetura e a migração, consulte Microsoft Fotos: Migrando da UWP para a SDK do Aplicativo Windows.

Quem está criando aplicativos .NET MAUI hoje?

As organizações usam .NET MAUI para criar aplicativos multiplataforma para Android, iOS, macOS e Windows. Veja exemplos na demonstração do cliente .NET.

Quem está desenvolvendo aplicativos WPF hoje?

A maior parte da interface do usuário Microsoft Visual Studio é criada com WPF. O Visual Studio IDE em si é um exemplo importante de um aplicativo WPF complexo e de alto desempenho.

Quem está criando aplicativos Blazor hoje?

O sistema de companhias aéreas FlightPulse da GE Digital usa Blazor para a configuração de back-end de tudo o que os pilotos veem, trazendo dados e análises do sensor diretamente aos pilotos para melhorar a segurança e a eficiência.

Veja mais histórias de clientes Blazor no site .NET.

Escolha de idioma (.NET vs C++)

Devo usar C# ou C++ para meu aplicativo de Windows?

Use C# (.NET) na maioria dos casos. O C# oferece desenvolvimento mais rápido, segurança de memória, bibliotecas avançadas e excelentes ferramentas. A maioria dos aplicativos Windows – incluindo WinUI 3, WPF, WinForms e aplicativos .NET MAUI – é melhor criada com C#.

Use C++ quando precisar de acesso direto de hardware, sobrecarga mínima de runtime ou interoperabilidade com as bases de código C++ existentes. Cenários comuns do C++ incluem mecanismos de jogo (DirectX), drivers, utilitários no nível do sistema e componentes críticos ao desempenho.

Fator C# (.NET) C++
Velocidade de desenvolvimento ✅ Mais rápido – memória gerenciada, ecossistema avançado ⚠️ Mais lento — gerenciamento manual de recursos
Desempenho em tempo de execução ✅Excelente com .NET moderno (AOT, Span<T>) ✅ Melhor possível – sem pausas de GC
Segurança de memória ✅ coletado do lixo ⚠️ Manual — risco de vazamentos e vulnerabilidades
acesso à API Windows ✅ Por meio da projeção C#/WinRT ✅ Via projeção C++/WinRT
Suporte ao WinUI 3 ✅ Suporte completo ✅ Suporte completo via C++/WinRT
Multiplataforma ✅.NET é executado em Windows, Linux e macOS ✅ Com código específico da plataforma
Melhor para Aplicativos empresariais, CRUD, serviços, aplicativos com muita interface de usuário Jogos, drivers, ferramentas do sistema, baixa latência

Você também pode misturar ambos: criar seu aplicativo em C# e chamar código nativo crítico de desempenho por meio de P/Invoke (CsWin32) ou um componente C++/WinRT.

Como posso chamar as APIs Win32 a partir de C#?

Use o CsWin32, um gerador de código-fonte que cria assinaturas P/Invoke fortemente tipadas durante a compilação. Adicione o Microsoft.Windows.CsWin32 pacote NuGet, liste as APIs necessárias em um NativeMethods.txt arquivo e chame-as por meio de uma classe gerada PInvoke .

O CsWin32 substitui declarações escritas à [DllImport] mão e funciona em qualquer projeto em C#, incluindo WinUI 3, WPF, WinForms e aplicativos de console. Consulte Como chamar APIs Win32 de um aplicativo Windows em C# (CsWin32) para ver um passo a passo.

O que é C++/WinRT e quando devo usá-lo?

C++/WinRT é uma projeção de linguagem C++17 padrão para APIs de Windows Runtime. Use-o ao criar aplicativos do Windows em C++ que usam ou definem APIs WinRT. Ele substitui C++/CX e a WRL (Biblioteca de Modelos Windows Runtime C++).

Escolha C++/WinRT quando:

  • Você está criando um aplicativo C++ WinUI 3
  • Você precisa criar componentes do Windows Runtime consumidos por outras linguagens
  • Você está migrando de C++/CX
O que é C#/WinRT e quando preciso?

O C#/WinRT fornece suporte à projeção do WinRT para C#. Na maioria dos casos, você não interage diretamente com isso — os aplicativos .NET destinados ao Windows obtêm automaticamente acesso às APIs do WinRT por meio de TFMs (monikers de framework de destino). Você precisa do C#/WinRT explicitamente ao criar componentes do Windows Runtime em C# ou ao gerar assemblies de interoperabilidade para componentes WinRT de terceiros.

Empacotamento, implantação e atualizações

Qual é a diferença entre aplicativos empacotados, desempacotados e empacotados com localização externa?

Um aplicativo empacotado contém seus arquivos, identidade e informações de implantação em um pacote como o MSIX. Um aplicativo não empacotado usa um instalador ou processo de implantação fora do sistema de pacotes Windows e não tem a identidade do pacote por padrão. Um aplicativo empacotado com localização externa usa um pequeno pacote de identidade, mantendo binários localizados externamente e seu processo de instalação e atualização existentes.

Consulte Visão geral do empacotamento para conhecer os requisitos e as vantagens e desvantagens envolvidas.

Preciso de identidade de pacote?

Depende dos recursos de Windows que seu aplicativo usa. A identidade do pacote é necessária para cenários como tarefas em segundo plano empacotadas, destinos de compartilhamento, tarefas de inicialização, extensões personalizadas de pacote de menu de contexto, associações de protocolo e tipo de arquivo baseadas em manifesto e muitas APIs de IA Windows. O SDK do Aplicativo Windows oferece suporte a notificações por push em cenários limitados de primeiro plano sem identidade, mas a entrega em segundo plano e a ativação via COM exigem identidade. O WinUI 3 e as notificações de aplicativo local podem funcionar sem a identidade do pacote.

Consulte Recursos que exigem identidade de pacote. Se você precisar de uma identidade de aplicativo, mas tiver que manter um instalador existente, considere o empacotamento com local externo.

Qual é a diferença entre a implantação dependente de estrutura e a implantação independente?

Um aplicativo dependente de framework usa os pacotes de runtime do SDK do Aplicativo Windows instalados separadamente no dispositivo. Isso reduz o tamanho da implantação do aplicativo e permite que a estrutura instalada receba atualizações de manutenção. Um aplicativo autocontido traz consigo as dependências do SDK do Aplicativo Windows, o que aumenta o tamanho da implantação e torna o publicador do aplicativo responsável por distribuir atualizações de manutenção do SDK do Aplicativo Windows junto com novas versões do aplicativo.

APIs que dependem de pacotes MSIX adicionais, como o pacote Singleton, podem exigir verificações separadas de implantação ou de suporte em tempo de execução, mesmo em um aplicativo autocontido. Empacotamento e implantação de runtime são decisões separadas. Confira Visão geral da implantação do SDK do Aplicativo Windows.

Meu aplicativo WinUI 3 será atualizado automaticamente para usuários finais?

Um aplicativo WinUI 3 pode ser disponibilizado pela Microsoft Store, por um arquivo .appinstaller, ou por um arquivo MSI ou um executável de instalação. Os pacotes da Loja podem ser atualizados por meio de serviços de Microsoft Store, sujeitos às configurações da Loja e da organização. Uma implantação de .appinstaller oferece suporte a atualizações automáticas somente quando UpdateSettings configura verificações de tempo de inicialização ou em segundo plano. A MSI e as implantações de configuração devem fornecer ou integrar seu próprio mecanismo de atualização.

Não posso usar SDK do Aplicativo Windows sem usar o MSBuild?

Sim, para alguns cenários. Atualmente, os projetos XAML do WinUI 3 exigem o MSBuild, embora Visual Studio não seja necessário e dotnet build possam invocar o MSBuild da linha de comando. Você pode usar APIs não XAML do SDK do Aplicativo Windows em projetos C++ e CMake por meio da aplicativo do Windows Development CLI em versão prévia, ou integrar manualmente o runtime.

IA do Windows

Como escolher entre Windows APIs de IA, Foundry Local e Windows ML?

As três primeiras tecnologias fazem parte da Microsoft Foundry no Windows. Você pode combiná-los uns com os outros e com modelos de nuvem no mesmo aplicativo:

  • Use as APIs de IA do Windows para recursos prontos para uso cujos modelos e a aceleração de hardware são gerenciados pelo Windows.
  • Use o Foundry Local para descobrir, baixar e executar modelos de fala e linguagem de software livre com suporte localmente.
  • Use Windows ML para executar seus próprios modelos ONNX com provedores de execução para hardware de CPU, GPU e NPU disponíveis.
  • Use Microsoft Foundry, uma plataforma de IA de nuvem separada, quando precisar de modelos hospedados na nuvem, recuperação, governança centralizada ou funcionalidades que não estejam disponíveis no dispositivo de destino.

Compare as opções em Escolher sua solução de IA Windows. Considere a funcionalidade do modelo, a privacidade, a conectividade, a latência, a cobertura de hardware, o tamanho da implantação e o custo operacional.

Os recursos de IA do Windows exigem um Copilot+ PC?

Nem todos eles. Muitas APIs de IA Windows exigem um Copilot+ PC, mas algumas APIs também dão suporte a GPUs ou CPUs específicas. O Foundry Local e Windows ML dão suporte a configurações de hardware mais amplas, sujeitas aos requisitos atuais de sistema operacional, modelo, runtime e provedor de execução.

Verifique a tabela de hardware da API de IA Windows e os requisitos para a API ou modelo específicos. Detecte o suporte e a preparação do modelo em tempo de execução e forneça um fallback que não seja de IA, de modelo local ou de nuvem quando o recurso não estiver disponível.

Os recursos de IA Windows podem ser executados localmente e offline?

Sim. Windows APIs de IA, Foundry Local e Windows ML podem executar inferência no dispositivo do usuário, o que pode reduzir a latência e manter os dados de entrada locais. Alguns modelos ou provedores de execução devem primeiro ser baixados ou provisionados e podem exigir uma conexão com a Internet durante a instalação ou a manutenção. Os serviços de IA de nuvem exigem conectividade e enviam dados para o serviço de acordo com seus termos de manipulação de dados.

Informe aos usuários quando um download de modelo é necessário e quando os dados saem do dispositivo. Não descreva um recurso como capaz de funcionar offline até que você tenha testado sua experiência completa na primeira execução, na atualização e no fallback.

As ferramentas de IA podem me ajudar a criar ou modernizar um aplicativo Windows?

Sim. Os agentes de codificação de IA podem ajudar a estruturar projetos, explicar APIs, migrar código, gerar testes e diagnosticar problemas de build. Use as orientações sobre desenvolvimento para Windows assistido por IA para o GitHub Copilot, o plug-in do agente WinUI, o servidor MCP do Microsoft Learn, os fluxos de trabalho de migração e os testes assistidos por IA.

Examine e teste o código gerado como qualquer outra contribuição. Em particular, verifique os nomes e as versões das APIs, as capacidades dos pacotes, o código sensível à segurança, a acessibilidade e quaisquer substituições de UWP por WinUI 3.

O que devo considerar antes de enviar um recurso assistido por IA?

Defina o uso e as limitações pretendidos do recurso, avalie a qualidade e a segurança com dados representativos, divulgue o comportamento da IA quando apropriado, proteja os dados do usuário e forneça um fallback quando o modelo ou hardware necessário não estiver disponível. Mantenha segredos e credenciais de serviço privilegiadas fora dos aplicativos cliente e exija a confirmação do usuário antes de ações conseqüentes ou irreversíveis. Consulte Desenvolvimento responsável de IA generativa no Windows e Segurança e IA responsável para o desenvolvimento no Windows.

Desempenho e otimização

O que posso fazer para fazer com que meu aplicativo Windows se sinta ótimo para os usuários finais?

Consulte Windows desenvolvimento de aplicativos – Melhores práticas e Windows visão geral do desempenho do aplicativo e conceitos básicos.

Compatibilidade

Meus usuários precisarão atualizar Windows para usar meu aplicativo WinUI 3?

O SDK do Aplicativo Windows tem um sistema operacional compatível mínimo de Windows 10, versão 1809, build 17763. O suporte da Microsoft requer uma versão com suporte do SDK do Aplicativo Windows com sua atualização de serviço mais recente, além de uma edição, versão e canal de manutenção do Windows que ainda tenha suporte. APIs individuais podem exigir uma versão Windows mais recente ou um hardware específico. Consulte o suporte do SDK do Aplicativo Windows e os canais de lançamento.

Posso direcionar o Arm64 com meu aplicativo WinUI 3?

Sim. Crie um aplicativo Arm64 nativo para obter o melhor desempenho e eficiência. Para uma base de código C++ grande com dependências x64, o Arm64EC permite migrar módulos incrementalmente. O Windows 11 para Arm também pode executar muitos aplicativos x86 e x64 existentes por meio da emulação Prism, mas você deve testar o desempenho e a compatibilidade em dispositivos Arm representativos.

Depreciações e migrações

A UWP/WinUI para UWP foi descontinuada?

UWP e WinUI 2 não foram formalmente preteridos. Visual Studio 2026 dá suporte à UWP com .NET moderno e AOT nativo, enquanto o WinUI 2.8 continua sendo a versão estável mais recente do WinUI para UWP. No entanto, Microsoft recomenda o WinUI 3 e o SDK do Aplicativo Windows para novos aplicativos de área de trabalho de Windows de uso geral.

O suporte UWP para .NET modernas com AOT Nativo geralmente está disponível e é o tipo de projeto UWP padrão em C# no Visual Studio 2026. Mover um aplicativo UWP existente do .NET Native para o .NET moderno é uma etapa de modernização separada da migração da interface do usuário para o WinUI 3. Consulte Modernizar seu aplicativo UWP com .NET e AOT nativo.

Quando devo migrar um aplicativo UWP / WinUI for UWP para o WinUI 3?

Os desenvolvedores da UWP não devem se sentir pressionados a migrar se estiverem satisfeitos com a UWP e seu conjunto de recursos , para muitos aplicativos, a opção certa pode ser permanecer na UWP.

Os aplicativos que desejam se beneficiar da plataforma de Windows mais recente e .NET investimentos devem considerar migrar para o WinUI 3 e o SDK do Aplicativo Windows. Consulte Migrate da UWP para o SDK do Aplicativo Windows.

Quando não devo migrar um aplicativo UWP + WinUI for UWP para o WinUI 3?

Continue usando a UWP quando seu dispositivo de destino ou modelo de aplicativo exigir, como aplicativos Xbox, aplicativos 2D HoloLens ou aplicativos para o ambiente padrão do Hub Surface. Windows IoT Enterprise dá suporte a tecnologias de aplicativos para desktop, incluindo o SDK do Aplicativo Windows, portanto um dispositivo IoT de destino não é, por si só, um motivo para usar UWP.

O WPF está obsoleto?

Não. O WPF tem suporte contínuo e continua recebendo melhorias de funcionalidade, desempenho, acessibilidade e estilo Fluent no .NET moderno. Ele continua sendo uma boa opção para aplicativos WPF existentes e para novos aplicativos cujos requisitos se encaixam WPF. Para novos aplicativos de área de trabalho de Windows de uso geral, a principal recomendação do Microsoft é o WinUI 3 com o SDK do Aplicativo Windows. Consulte o roteiro WPF em GitHub.

O WinForms está obsoleto?

Não. O WinForms tem suporte e continua recebendo atualizações de recursos. Consulte o roteiro Windows Forms em GitHub.

O Windows Runtime (WinRT) foi descontinuado?

Não. O WinRT é uma ABI (interface binária de aplicativo) que permite interoperabilidade em vários idiomas. O WinRT é a evolução do COM e o SDK do Aplicativo Windows fornece a maior parte de sua funcionalidade por meio de APIs do WinRT.

Notas de lançamento

Onde posso encontrar notas de versão para o SDK do Aplicativo Windows?

Consulte as notas de versão SDK do Aplicativo Windows para versões estáveis, prévias e experimentais. A página Novidades para desenvolvedores Windows resume o SDK, SDK do Aplicativo Windows, WinUI 3, ferramentas e atualizações de plataforma Windows mais recentes.

Conteúdo relacionado

  • Last updated on