Perguntas Frequentes sobre Desenvolvimento de Aplicação do Windows

Para uma visão geral das opções atuais para programadores Windows, veja o episódio do Windows Dev Chat Escolher a sua plataforma de desenvolvimento ideal, que aborda WinUI 3, .NET MAUI, React Native, Blazor e Progressive Aplicações Web (PWAs). Podes encontrar outros episódios na playlist do Windows Dev Chat.

Também pode consultar a visão geral das opções de desenvolvimento de aplicações para programadores para Windows.

Na era dos serviços na cloud, o desenvolvimento de aplicações cliente continua a ser importante para proporcionar interações responsivas e significativas nos dispositivos dos utilizadores.

Eis porque as aplicações clientes são importantes:

• Alcance do dispositivo: As aplicações clientes permitem-lhe levar a sua aplicação diretamente aos utilizadores nos seus dispositivos preferidos.
• Gateway para Serviços Inteligentes: As aplicações cliente são frequentemente a primeira interação dos utilizadores com os seus serviços. Eles oferecem uma interface rica e interativa que permite que você exiba recursos inteligentes e diferencie seu produto dos outros.
• Escalabilidade com Integração na Cloud: Uma aplicação cliente bem integrada pode sincronizar facilmente com os serviços de backend na cloud, permitindo acesso a dados em tempo real e escalabilidade fluida à medida que a sua base de utilizadores cresce.
• Maior produtividade 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.

O SDK de Aplicações Windows fornece componentes independentes para aplicações de ambiente de trabalho Windows, incluindo WinUI 3, ciclo de vida da aplicação, janelas, notificações, recursos e APIs de texto. Suporta aplicações que correm no Windows 10, versão 1809 e posteriores, sujeitas ao ciclo de vida de suporte das versões do Windows e do SDK de Aplicações Windows.

Ambos são kits de desenvolvimento de software (SDKs) que permitem criar aplicações para Windows.

O SDK de Aplicações Windows fornece componentes que são fornecidos de forma independente do Windows e funcionam entre versões suportadas do Windows até ao Windows 10, versão 1809. Inclui o WinUI 3 e APIs para ciclo de vida da aplicação, janelas, notificações, recursos, texto e outras funcionalidades.

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

O SDK de Aplicações Windows não substitui o Windows SDK. As aplicações que adotam o SDK de Aplicações Windows podem continuar a usar APIs do Windows SDK, e as aplicações WinUI 3 costumam usar ambas.

Aqui estão algumas razões para escolher uma framework Windows nativa para a sua aplicação exclusiva do Windows:

• Performance: Os frameworks nativos de Windows são otimizados para tirar partido do hardware Windows moderno, proporcionando experiências de utilizador rápidas e responsivas.
• Integration: Windows vem com uma grande variedade de APIs que permitem experiências sofisticadas disponíveis apenas em Windows. Frameworks nativos proporcionam uma integração profunda com estas funcionalidades e APIs.
• Experiência de utilizador nativa: Os frameworks nativos proporcionam uma experiência consistente em dispositivos Windows, garantindo que a sua aplicação tenha um aspeto e funcione perfeitamente em qualquer lugar.
• Suporte offline: Frameworks nativos suportam cenários offline, permitindo que as aplicações funcionem mesmo sem ligação à internet.
• Suporte e ferramentas: A Microsoft mantém os frameworks nativos e fornece SDKs atuais, documentação, ferramentas de depuração e exemplos.

Se estiver a desenvolver uma nova aplicação de ambiente de trabalho Windows de uso geral, recomendamos o uso do WinUI 3. O WinUI 3 é o framework nativo de interface fornecido com o SDK de Aplicações Windows. Suporta aplicações de ambiente de trabalho Windows e fornece acesso aos controlos atuais do Fluent e às capacidades da plataforma Windows.

Note que o WinUI 3 (um framework de interface de utilizador) vem com o SDK de Aplicações Windows (um framework de desenvolvimento para plataforma Windows).

Pode migrar a interface de uma aplicação para o WinUI 3, ou usar ilhas XAML do WinUI para alojar controlos do SDK de Aplicações Windows num alojamento desktop já suportado. As ilhas XAML do sistema legado alojam controlos UWP XAML e utilizam diferentes APIs.

Elementos do SDK de Aplicações Windows podem frequentemente ser usados em aplicações de ambiente de trabalho, dependendo de como a aplicação existente foi construída. As aplicações UWP não são suportadas pelo SDK de Aplicações Windows.

Isto significa que as aplicações WPF/MFC/WinForms podem usar APIs do SDK de Aplicações Windows que não estão relacionadas com o WinUI 3. Exemplos incluem o ciclo de vida da aplicação, janelas e notificações da app.

Consulte Use o SDK de Aplicações Windows num projeto existente para mais informações.

Não. As builds XAML do WinUI 3 usam o MSBuild, mas podes compilar com o SDK .NET e os templates atuais do WinUI 3 a partir da linha de comandos noutro editor. Veja o quickstart da linha de comandos.

O Visual Studio 2026 oferece a experiência integrada mais rica de edição, depuração, perfilação e XAML Hot Reload. Use o fluxo de trabalho que corresponda aos seus requisitos de ferramentas.

Este erro ocorre normalmente em cenários de aplicações não embaladas em que o tempo de execução do SDK de Aplicações Windows não foi instalado na máquina. Experimente o seguinte:

• Se estiveres a usar uma aplicação packaged (o padrão recomendado), certifica-te de que estás a iniciar via Visual Studio com o perfil de lançamento MsixPackage selecionado (não o perfil do executável simples). A etapa de empacotamento MSIX instala os componentes de runtime necessários.
• Se estiver a executar uma aplicação não empacotada dependente de estrutura, instale o runtime correspondente do SDK de Aplicações Windows. Uma implementação autónoma inclui as suas dependências do SDK de Aplicações Windows.
• Confirma se o teu projeto corresponde ao teu modelo de implementação. Para uma aplicação .NET normal e não empacotada, a definição <WindowsPackageType>None</WindowsPackageType> ativa a inicialização automática do SDK de Aplicações Windows em tempo de execução. Usa a API do bootstrapper diretamente apenas quando precisares de controlo explícito sobre a inicialização dinâmica de dependências.

Consulte Deploy apps que utilizam o SDK de Aplicações Windows para mais detalhes sobre os requisitos de implementação.

O WinUI 3 é o atual framework nativo de interface da Microsoft para aplicações de ambiente de trabalho Windows e é fornecido como parte do SDK de Aplicações Windows.

O WinUI 2, também chamado de WinUI para UWP, é uma biblioteca de controlo e estilo para aplicações UWP. O WinUI 2 e o WinUI 3 usam namespaces XAML diferentes e não são compatíveis com binários.

Yes. Aplicação WinUI 3 é o termo mais claro para uma aplicação cuja interface utiliza WinUI 3 e o SDK de Aplicações Windows. A aplicação WinUI também é frequentemente usada quando o contexto é inequívoco.

Não. O SDK de Aplicações Windows não pode ser usado em aplicações UWP, e o WinUI para UWP não pode ser combinado com o WinUI 3. Ver Migrar do UWP para o SDK de Aplicações Windows.

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

1. Customização do ficheiro de projeto e do MSBuild: O esforço de migração varia consoante o uso avançado do MSBuild.
2. Migração da API .NET: Aplicações UWP que usam .NET Native podem migrar para uma versão .NET atualmente suportada com Native AOT. Esta modernização é separada da migração da interface para o WinUI 3.
3. Bibliotecas de componentes UI: As bibliotecas devem ter versões direcionadas para o WinUI 3.
4. APIs de janelas e do modelo de aplicações: As APIs UWP associadas a conceitos como CoreWindow, ApplicationView ou GetForCurrentView exigem alternativas no SDK de Aplicações Windows ou outra abordagem para ambiente de trabalho.
5. Projeção da linguagem C++: Se a aplicação UWP usar a projeção C++/CX substituída, porte esse código para C++/WinRT.

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

Sim, as aplicações atualizadas podem ser publicadas sem atualizar a identidade da aplicação. Os utilizadores da versão antiga serão atualizados para a nova versão. Isto aplica-se apenas a aplicações de ambiente de trabalho. Xbox, HoloLens e aplicações padrão do Surface Hub não podem migrar para o WinUI 3.

Consulte a Visão geral da criação de pacotes e implementação.

Ver Migrar do UWP para o SDK de Aplicações Windows.

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

• Migração do UWP para o WinUI 3: Muitos conceitos de XAML e UI mantêm-se, mas os namespaces, o modelo do projeto e algumas APIs diferem.
• Migração do WPF para o WinUI 3: Muitos conceitos são mantidos, mas o conjunto de controlos e as APIs diferem.

Atualmente, não. Use XAML Hot Reload, Live Visual Tree, Live Property Explorer e ferramentas de runtime relacionadas para inspecionar e atualizar XAML enquanto a aplicação está a correr.

Para uma explicação completa das ferramentas de design em tempo de execução disponíveis para o WinUI 3, consulte ferramentas de design em tempo de execução XAML para o WinUI 3.

Yes. O WinUI 3 é fornecido como parte do SDK do Aplicativo Windows.

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

Não exatamente. Embora o WinUI 3 tenha começado a partir da base de código WinUI para UWP, são tecnologias distintas. Ambos são frameworks de interface baseados em XAML que funcionam em .NET e C++, mas o WinUI para UWP e o WinUI 3 não são compatíveis entre si.

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

Yes. O WinUI 3 e muitas APIs do SDK de Aplicações Windows funcionam em aplicações não integradas. No entanto, algumas funcionalidades do Windows exigem identidade de pacote, e as aplicações não embaladas dependentes do framework têm de inicializar o runtime do SDK de Aplicações Windows. Compare as opções na visão geral da embalagem e as funcionalidades que exigem identidade da embalagem.

O WinUI 3 é a estrutura de interface incluída no SDK de Aplicações Windows. XAML Islands é uma técnica de alojamento que permite a uma aplicação de ambiente de trabalho existente alojar conteúdo XAML lado a lado com a interface de utilizador de outro framework.

O termo pode referir-se às antigas System XAML Islands, que alojam controlos UWP XAML, ou às WinUI XAML Islands, que alojam controlos do SDK de Aplicações Windows em anfitriões de ambiente de trabalho suportados. As APIs, os espaços de nomes e os requisitos do anfitrião são diferentes.

Os controlos do WinUI 3 utilizam o estilo Fluent nas versões suportadas do Windows 10 e Windows 11, tanto em aplicações embaladas como não embaladas. Alguns efeitos e comportamentos do sistema operativo diferem consoante a versão do Windows. Por exemplo, o Mica está disponível no Windows 11 e volta a uma cor sólida no Windows 10.

Yes. O Desktop Acrylic é suportado no Windows 10, versão 1809 e posteriores. O Mica requer o Windows 11 e volta a ter uma cor de tema sólida no Windows 10. Chame MicaController.IsSupported ou DesktopAcrylicController.IsSupported durante a execução antes de aplicar um plano de fundo. Consulte Aplicar materiais de Mica ou Acrílico em aplicações de desktop para Windows 11.

Consulte Exemplo e recursos. Alguns repositórios notáveis:

• WindowsAppSDK-Samples: Demonstra como usar conjuntos específicos de APIs SDK de Aplicações Windows.
• Exemplos específicos de tópicos para Windows: Contém o exemplo usado no tutorial da aplicação de notas Build a WinUI 3.
• WinUI 3 Galeria: Apresenta o WinUI e o SDK de Aplicações Windows. Também disponível no Microsoft Store.

Se já investiu bastante no WPF, pode continuar a usá-lo para aplicações existentes. O WPF é uma framework madura e estável, amplamente utilizada para construir aplicações de ambiente de trabalho para Windows.

Utilize o GitHub Copilot upgrade para avaliar e atualizar uma aplicação WPF em .NET Framework para o .NET moderno. Revise o plano gerado e valide cada alteração na sua aplicação.

Ao desenvolver uma aplicação WPF com .NET 9 ou posterior, pode garantir que a sua aplicação corresponde ao aspeto moderno e elegante do Windows 11. O novo tema Fluent para WPF introduz uma estética contemporânea do Windows 11, com modo Claro/Escuro integrado e suporte a cores de destaque do sistema. Isto moderniza a aparência da sua aplicação e proporciona uma experiência de utilizador polida e coesa.

Se o WinForms responder às suas necessidades e a sua equipa se sentir confortável com ele, pode continuar a usar o WinForms para aplicações existentes. O WinForms é uma framework madura e estável, amplamente utilizada para o desenvolvimento de ambiente de trabalho Windows.

A equipa WinForms continua a investir na plataforma. Trabalhos recentes e em curso incluem:

• APIs de formulário e diálogo assíncronas
• Modo escuro e suporte a estilo visual
• Acessibilidade, DPI elevado, layout e melhorias de design
• Prancheta e DataObject modernização

Se estiver a direcionar utilizadores em várias plataformas de SO, construir aplicações de plataforma cruzada com .NET MAUI ou React Native pode apresentar diversos benefícios.

• Alcance: As aplicações multiplataforma alcançam um público maior através de diferentes dispositivos e sistemas operativos.
• Reutilização de código: Reutilizar código entre plataformas reduz o tempo e o custo de desenvolvimento. Construir aplicações separadas para Windows, Android, iOS e macOS pode ser proibitivamente caro.
• Experiência de utilizador consistente: Os frameworks multiplataforma ajudam a proporcionar uma aparência e sensação consistentes entre plataformas.
• Integração: As aplicações multiplataforma ainda podem integrar-se com serviços específicos da plataforma para proporcionar uma experiência abrangente.

Quando constróis uma aplicação .NET MAUI para Windows, a saída usa o WinUI 3. Durante o desenvolvimento, o .NET MAUI oferece uma experiência .NET consistente em várias plataformas, mas gera código específico para cada plataforma nos bastidores.

O .NET MAUI oferece uma experiência unificada de .NET em Windows, iOS, Android e macOS. Oferece APIs multiplataforma para capacidades comuns, como armazenamento, redes e sensores de dispositivos. Também pode chamar APIs específicas da plataforma ou fornecer implementações especializadas para cada plataforma.

Neste momento, não. Embora o .NET MAUI utilize o WinUI 3 quando corre no Windows, as equipas que esperem atingir várias plataformas devem começar com .NET MAUI ou React Native para Ambiente de Trabalho.

Equipas com forte experiência em desenvolvimento web podem querer considerar o React Native para Desktop. Inclui React Native para Windows e macOS. Com a abordagem "Aprenda uma vez, escreva em qualquer lugar", as competências existentes em JavaScript, TypeScript e React podem ser usadas para criar aplicações nativas para Windows e macOS.

O React Native for Desktop renderiza a interface diretamente para primitivas nativas, oferecendo desempenho nativo e capacidades de plataforma.

Veja a documentação do React Native para Desktop para começar.

O React Native para Windows suporta as versões do Windows listadas na sua documentação de compatibilidade. Verifique o suporte da família de dispositivos para a versão React Native para Windows que pretende em vez de assumir que todos os dispositivos Windows são suportados.

Para uma aplicação Xbox, usa UWP e tem em conta as limitações específicas de UWP da Xbox. Para desenvolvimento de jogos, usa o Kit de desenvolvimento de jogos da Microsoft.

Para um Surface Hub que execute o ambiente padrão Teams Rooms ou Surface Hub, utilize uma aplicação UWP que cumpra os requisitos da aplicação Surface Hub. Um Surface Hub 3 configurado com Windows 11 Pro ou Enterprise pode correr tecnologias de aplicações de ambiente de trabalho suportadas, por isso o UWP não é a única opção nessa configuração.

Os aplicativos híbridos combinam o melhor do desenvolvimento de aplicativos nativos e da Web. O seu núcleo é construído usando tecnologias web como HTML, CSS e JavaScript, e está envolto num contentor nativo que dá acesso a certas funcionalidades e hardware nativos da plataforma. Eles também podem ser distribuídos através de lojas de aplicativos.

A principal vantagem é que as aplicações híbridas permitem construir uma única aplicação que pode correr em múltiplas plataformas nativas e na web, reduzindo o tempo e custos de desenvolvimento. Exemplos de plataformas híbridas de desenvolvimento de aplicações incluem:

• Electron para aplicações de ambiente de trabalho
• Ionic para aplicações móveis
• .NET MAUI Blazor Hybrid para aplicações multiplataforma

Ver Desenvolvimento Web em Windows e Visão Geral do Progressive Aplicações Web.

Com .NET MAUI, as aplicações Blazor podem correr nativamente no Windows, iOS, Android e macOS. Isto permite-lhe criar aplicações cliente híbridas que combinam componentes Blazor e .NET MAUI numa única aplicação cliente nativa, com acesso total às capacidades nativas da plataforma.

Saiba mais em ASP.NET Core Blazor Hybrid.

Não. A partir do .NET 9, o .NET MAUI inclui um controlo HybridWebView que permite alojar outras interfaces baseadas em JavaScript dentro de uma aplicação nativa.

Isto permite-lhe alojar aplicações Angular, React, Vue ou outras aplicações HTML/JavaScript dentro de uma aplicação .NET MAUI. O controlo híbrido proporciona interoperabilidade entre C# e JavaScript, pelo que o código C# pode chamar funções JavaScript e vice-versa.

Yes. As aplicações WPF e WinForms também podem alojar componentes híbridos Blazor, permitindo a adição de interfaces web modernas às aplicações existentes. Isto não é suportado para aplicações WPF ou WinForms construídas no .NET Framework.

Componentes nativos e híbridos podem ser misturados dentro de uma aplicação. Por exemplo, o núcleo de uma aplicação pode ser construído com componentes .NET MAUI, enquanto componentes híbridos fornecem funcionalidades adicionais. Isto permite combinar o desempenho e as capacidades dos componentes nativos com a flexibilidade e eficiência de custos dos componentes híbridos.

As Web apps oferecem o alcance mais amplo de qualquer plataforma de aplicações cliente. Opções para criar belas aplicações web .NET incluem:

• Aplicações ASP.NET Core com Razor Pages
• Aplicações ASP.NET Core MVC
• Aplicações ASP.NET Core Blazor, com opções de modelo de alojamento:
  • Blazor WebAssembly (estrutura para desenvolvimento de aplicações web)
  • Blazor Server

Os modelos de alojamento Blazor podem agora ser configurados ao nível do componente, permitindo cenários como alojar um componente Blazor WebAssembly numa aplicação Blazor Server.

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

O Windows é uma plataforma aberta que suporta muitas tecnologias. Aqui estão alguns critérios que podem ajudar a escolher uma plataforma:

• Está a priorizar o Windows ou a desenvolver para várias plataformas?
• Que linguagens ou competências já tens — .NET, JavaScript, outra coisa?
• Precisas de acesso a APIs específicas do Windows?
• Qual das capacidades do framework correspondem melhor aos requisitos da sua aplicação?
• Consulte esta tabela para fatores de comparação adicionais.

Para muitas aplicações empresariais, as equipas escolhem frequentemente com base nas competências existentes e no que a equipa se sente mais confortável a usar.

Considere o seguinte ao escolher uma abordagem de desenvolvimento para a sua aplicação web:

• O Blazor é recomendado para construir aplicações web front-end com .NET. Permite construir tanto o front-end como o back-end usando .NET, poupando tempo e custos, e é especialmente bom para aplicações empresariais.
• As web apps em JavaScript continuam a fazer sentido se quiseres tirar partido das competências existentes em JavaScript ou se precisares de integrar com bibliotecas ou frameworks JS já estabelecidos.
• As aplicações existentes que utilizam frameworks mais antigos como Web Forms, MVC ou Razor Pages continuam a ser suportadas e podem continuar a ser desenvolvidas e mantidas.

O Microsoft Photos é um exemplo documentado. A aplicação migrou do UWP para o SDK de Aplicações Windows e continua a usar o WinUI 3. Para detalhes sobre a arquitetura e migração, consulte Microsoft Photos: Migração de UWP para SDK de Aplicações Windows.

As organizações utilizam .NET MAUI para construir aplicações multiplataforma para Android, iOS, macOS e Windows. Veja exemplos na apresentação de clientes .NET.

A maior parte da interface Microsoft Visual Studio é construída com WPF. O próprio IDE Visual Studio é um exemplo importante de uma aplicação de WPF complexa e de alto desempenho.

O sistema de companhias aéreas FlightPulse da GE Digital utiliza o Blazor para a configuração backend de tudo o que os pilotos veem, levando dados e análises de sensores diretamente aos pilotos para melhorar a segurança e eficiência.

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

Usa C# (.NET) na maioria dos casos. O C# oferece desenvolvimento mais rápido, segurança de memória, bibliotecas ricas e ferramentas excelentes. A maioria das aplicações Windows — incluindo WinUI 3, WPF, WinForms e aplicações .NET MAUI — é melhor construída com C#.

Use C++ quando precisar de acesso direto ao hardware, sobrecarga mínima em tempo de execução ou interoperar com bases de código C++ existentes. Cenários comuns em C++ incluem motores de jogo (DirectX), drivers, utilitários ao nível do sistema e componentes críticos de desempenho.

Fator	C# (.NET)	C++
Velocidade de desenvolvimento	✅ Mais rápido — memória gerida, ecossistema rico	⚠️ Mais lento — gestão manual de recursos
Desempenho em tempo de execução	✅Excelente para .NET moderno (AOT, Span<T>)	✅ O melhor possível — sem pausas no GC
Segurança de memória	✅ Recolha de lixo	⚠️ Manual — risco de fugas e vulnerabilidades
Acesso à API do Windows	✅ Via projeção C#/WinRT	✅ Via projeção C++/WinRT
Suporte ao WinUI 3	✅ Suporte completo	✅ Suporte total via C++/WinRT
Multiplataforma	✅.NET corre em Windows, Linux, macOS	✅ Com código específico de cada plataforma
Melhor para	Aplicações empresariais, CRUD, serviços, aplicações com muita interface de utilizador	Jogos, controladores, ferramentas do sistema, baixa latência

Também pode misturar ambos: construir a sua aplicação em C# e chamar código nativo crítico de desempenho via P/Invoke (CsWin32) ou um componente C++/WinRT.

Utilize CsWin32, um gerador de código que cria assinaturas P/Invoke com segurança de tipos durante a compilação. Adiciona-se o Microsoft.Windows.CsWin32 pacote NuGet, lista as APIs de que precisa num NativeMethods.txt ficheiro e chama-as através de uma classe gerada PInvoke .

O CsWin32 substitui declarações manuscritas [DllImport] e funciona em qualquer projeto C#, incluindo WinUI 3, WPF, WinForms e aplicações de consola. Consulte Chamar APIs Win32 a partir de uma aplicação Windows em C# (CsWin32) para um guia passo a passo.

C++/WinRT é uma projeção padrão da linguagem C++17 para APIs do Windows Runtime. Use-o ao construir aplicações Windows em C++ que consomam ou criam APIs WinRT. Substitui o C++/CX e a Windows Runtime C++ Template Library (WRL).

Escolha C++/WinRT quando:

• Estás a construir uma aplicação WinUI 3 em C++
• Tem de criar componentes do Windows Runtime utilizados por outras linguagens
• Está a migrar de C++/CX

C#/WinRT fornece suporte de projeção WinRT para C#. Na maioria dos casos, não interage diretamente com ele — as aplicações .NET direcionadas ao Windows têm acesso automático às APIs do WinRT através dos nomes de framework de destino (TFMs). É necessário C#/WinRT explicitamente ao criar componentes Windows Runtime em C# ou ao gerar assemblies de interoperabilidade para componentes WinRT de terceiros.

Uma aplicação empacotada contém os seus ficheiros, identidade e informações de implementação num pacote como o MSIX. Uma aplicação não empacotada usa um instalador ou processo de implementação fora do sistema de pacotes do Windows e não tem identidade de pacote por defeito. Uma aplicação com localização externa utiliza um pequeno pacote de identidade, mantendo binários localizados externamente e o seu processo de instalação e atualização existente.

Consulte a visão geral da embalagem para requisitos e compensações.

Depende das funcionalidades do Windows que a sua aplicação utiliza. A identidade do pacote é necessária para cenários como tarefas em segundo plano empacotadas, alvos de partilha, tarefas de arranque, extensões personalizadas de pacotes em menus contextuais, associações de tipos de ficheiros e protocolos baseadas em manifestos, e muitas APIs de IA do Windows. Notificações push do SDK de Aplicações Windows suportam cenários em primeiro plano limitados sem identidade, mas a entrega em segundo plano e a ativação do COM exigem identidade. O WinUI 3 e as notificações de aplicações locais podem funcionar sem identidade de pacote.

Consulte Funcionalidades que exigem identidade do pacote. Se precisar de uma identidade de aplicação, mas tiver de manter um instalador existente, considere o empacotamento com localização externa.

Uma aplicação dependente do framework utiliza pacotes de runtime do SDK de Aplicações Windows instalados separadamente no dispositivo. Isto reduz o tamanho de implementação da aplicação e permite que o framework instalado receba atualizações de manutenção. Uma aplicação autónoma carrega consigo as suas dependências do SDK de Aplicações Windows, o que aumenta o tamanho da implementação e torna o editor responsável por distribuir as atualizações de manutenção do SDK de Aplicações Windows com as novas versões da aplicação.

APIs que dependem de pacotes MSIX adicionais, como o pacote Singleton, podem exigir verificações separadas de implementação ou suporte em tempo de execução, mesmo numa aplicação autónoma. O empacotamento e a implementação em tempo de execução são decisões separadas. Consulte visão geral da implantação do SDK de Aplicativo Windows.

Uma aplicação WinUI 3 pode ser entregue através da Microsoft Store, um .appinstaller ficheiro, um MSI ou executável de configuração. Os pacotes da Microsoft Store podem ser atualizados através do serviço de atualização da Microsoft Store, sujeitos às definições da Store e da organização. Uma .appinstaller implementação suporta atualizações automáticas apenas quando UpdateSettings configura a hora de lançamento ou verificações de antecedentes. As implementações MSI e de setup devem fornecer ou integrar o seu próprio mecanismo de atualização.

Sim, para alguns cenários. Os projetos XAML do WinUI 3 atualmente requerem o MSBuild, embora o Visual Studio não seja obrigatório e dotnet build possa invocar o MSBuild a partir da linha de comandos. Pode utilizar APIs não XAML do SDK de Aplicações Windows em projetos C++ e CMake através da versão de pré-visualização da CLI do Aplicação do Windows Development ou integrar manualmente o runtime.

As três primeiras tecnologias fazem parte do Microsoft Foundry no Windows. Pode combiná-los entre si e com modelos cloud na mesma aplicação:

• Use as APIs de IA do Windows para capacidades prontas a usar cujos modelos e aceleração de hardware o Windows gere.
• Use Foundry Local para descobrir, transferir e executar localmente modelos de linguagem e de voz de código aberto suportados.
• Use Windows ML para correr os seus próprios modelos ONNX com fornecedores de execução para hardware de CPU, GPU e NPU disponíveis.
• Use o Microsoft Foundry, uma plataforma de IA na cloud separada, quando precisar de modelos alojados na cloud, recuperação, governação centralizada ou capacidades que não estejam disponíveis no dispositivo alvo.

Compare as opções em Escolha a sua solução de IA para Windows. Considere a capacidade do modelo, privacidade, conectividade, latência, cobertura de hardware, tamanho de implementação e custo operacional.

Nem todos. Muitas APIs de IA do Windows requerem um Copilot+ PC, mas algumas APIs também suportam GPUs ou CPUs específicas. O Foundry Local e o Windows ML suportam configurações de hardware mais amplas, sujeitas aos requisitos atuais do sistema operativo, modelo, tempo de execução e fornecedor de execução.

Consulte a tabela de hardware da API de IA do Windows e os requisitos para a API ou modelo específico. Verifique o suporte e o estado de preparação do modelo em tempo de execução e forneça uma alternativa sem IA, com modelo local ou na nuvem quando a funcionalidade não estiver disponível.

Yes. As APIs de IA do Windows, o Foundry Local e o Windows ML podem executar inferência no dispositivo do utilizador, o que pode reduzir a latência e manter os dados de entrada locais. Alguns modelos ou fornecedores de execução devem primeiro ser descarregados ou provisionados e podem requerer uma ligação à internet durante a configuração ou manutenção. Os serviços de IA na nuvem requerem conectividade e enviam dados para o serviço de acordo com os seus termos de tratamento de dados.

Informe os utilizadores quando é necessário descarregar um modelo e quando os dados saem do dispositivo. Não descreva uma funcionalidade como capaz de funcionar offline antes de ter testado toda a experiência da primeira execução, da atualização e do recurso de reserva.

Yes. Agentes de programação com IA podem ajudar a criar a estrutura base de projetos, explicar APIs, migrar código, gerar testes e diagnosticar problemas de compilação. Use as orientações de desenvolvimento Windows assistidas por IA para o GitHub Copilot, o plugin do agente WinUI, o Microsoft Learn MCP Server, fluxos de trabalho de migração e testes assistidos por IA.

Revê e testa o código gerado como farias com qualquer outra contribuição. Em particular, verifique nomes e versões das APIs, capacidades dos pacotes, código sensível à segurança, acessibilidade e quaisquer substituições de UWP para WinUI 3.

Defina o uso pretendido e as limitações da funcionalidade, avalie a qualidade e segurança com dados representativos, divulgue o comportamento da IA quando apropriado, proteja os dados dos utilizadores e forneça uma alternativa quando o modelo ou o hardware necessário não estiver disponível. Mantenha segredos e credenciais de serviço privilegiadas fora das aplicações clientes, e exija confirmação do utilizador antes de ações consequentes ou irreversíveis. Veja Desenvolvimento responsável de IA generativa no Windows e Segurança e IA responsável pelo desenvolvimento no Windows.

Consulte Desenvolvimento de aplicações para Windows - Melhores práticas e performance e fundamentos das aplicações Windows – visão geral.

O SDK de Aplicações Windows tem um sistema operativo mínimo compatível com Windows 10, versão 1809, versão 17763. O suporte da Microsoft exige uma versão suportada do SDK de Aplicações Windows com a sua atualização de manutenção mais recente e uma edição, versão e canal de manutenção do Windows que ainda são suportados. APIs individuais podem exigir uma versão mais recente do Windows ou hardware específico. Consulte o suporte ao SDK de Aplicações Windows e os canais de lançamento.

Yes. Constrói uma aplicação Arm64 nativa para obter o melhor desempenho e eficiência. Para uma grande base de código C++ com dependências x64, o Arm64EC permite migrar módulos de forma incremental. O Windows 11 no Arm também pode correr muitas aplicações x86 e x64 existentes através da emulação Prism, mas deve testar o desempenho e a compatibilidade em dispositivos Arm representativos.

O UWP e o WinUI 2 não estão formalmente obsoletos. O Visual Studio 2026 suporta UWP com .NET moderno e AOT nativo, enquanto o WinUI 2.8 continua a ser a versão estável mais recente do WinUI para UWP. No entanto, a Microsoft recomenda o WinUI 3 e o SDK de Aplicações Windows para novas aplicações de ambiente de trabalho Windows de uso geral.

O suporte UWP para .NET moderno com AOT nativo está geralmente disponível e é o tipo padrão de projeto UWP em C# no Visual Studio 2026. Mover uma aplicação UWP existente do .NET Nativo para o .NET moderno é um passo de modernização separado da migração da interface para o WinUI 3. Veja Modernizar a sua aplicação UWP com .NET e AOT nativo.

Os programadores de UWP não devem sentir-se pressionados a migrar se estiverem satisfeitos com o UWP e o seu conjunto de funcionalidades — para muitas aplicações, a escolha certa pode ser permanecer no UWP.

As aplicações que queiram beneficiar da mais recente plataforma Windows e dos investimentos em .NET devem considerar migrar para o WinUI 3 e o SDK de Aplicações Windows. Ver Migrar do UWP para o SDK de Aplicações Windows.

Continue a usar UWP quando o seu dispositivo ou modelo de aplicação de destino o exigir, como aplicações Xbox, aplicações HoloLens 2D ou aplicações para o ambiente padrão do Surface Hub. O Windows IoT Enterprise suporta tecnologias de aplicações de ambiente de trabalho, incluindo o SDK de Aplicações Windows, pelo que um destino IoT não é, por si só, uma razão para usar UWP.

Não. O WPF é suportado e continua a receber melhorias de funcionalidades, desempenho, acessibilidade e estilo Fluent no .NET moderno. Continua a ser uma boa escolha para aplicações WPF existentes e para novas aplicações cujos requisitos se adequam ao WPF. Para novas aplicações de ambiente de trabalho Windows de uso geral, a principal recomendação da Microsoft é o WinUI 3 com o SDK de Aplicações Windows. Consulte o roteiro WPF em GitHub.

Não. O WinForms é suportado e continua a receber atualizações de funcionalidades. Consulte o Roadmap Windows Forms em GitHub.

Não. WinRT é uma interface binária de aplicação (ABI) que permite a interoperabilidade entre várias línguas. O WinRT é a evolução do COM, e o SDK de Aplicações Windows fornece a maior parte da sua funcionalidade através das APIs WinRT.

Consulte as notas de lançamento do SDK de Aplicações Windows para versões estáveis, de pré-visualização e experimentais. A página O que há de novo para programadores Windows resume os mais recentes Windows SDK, SDK de Aplicações Windows, WinUI 3, ferramentas e atualizações da plataforma.