Visão geral da implementação do SDK de Aplicações Windows

Existem duas formas de implementar o SDK de Aplicações Windows:

  • dependente do quadro . A sua aplicação depende de o runtime do SDK de Aplicações Windows e/ou o pacote Framework estarem presentes na máquina de destino. A implementação dependente do framework é o modo de implementação padrão do SDK de Aplicações Windows devido à sua utilização eficiente dos recursos da máquina e à sua funcionalidade.
  • autossuficiente. A sua aplicação inclui as dependências do SDK de Aplicações Windows, eliminando a necessidade de uma instalação separada do runtime na máquina de destino.

Este tópico também usa os termos aplicação embalada, aplicação embalada com localização externae aplicação não embalada. Para obter esclarecimentos sobre esses termos, consulte a Visão geral da implementação.

Implementação dependente do framework Implantar autossuficiente
Vantagens Pequena implantação. Apenas a sua aplicação e as suas outras dependências são distribuídas. O runtime e o pacote Framework do SDK de Aplicações Windows são instalados automaticamente por aplicações dependentes do framework que são empacotadas; ou como parte do instalador de runtime do SDK de Aplicações Windows por aplicações dependentes do framework que são embaladas com localização externa ou não empacotadas.

Funcionável. As atualizações de serviço ao SDK de Aplicações Windows são instaladas automaticamente através do pacote SDK de Aplicações Windows Framework, sem necessidade de qualquer ação da aplicação.		 Controlar a versão do SDK de Aplicações Windows. Você controla qual versão da SDK de Aplicações Windows é distribuída com a sua aplicação. Atualizações de manutenção do SDK de Aplicações Windows não vão afetar o seu aplicativo, a menos que você o reconstrua e redistribua.

Isolado de outras aplicações. As aplicações e utilizadores não podem desinstalar a sua dependência do SDK de Aplicações Windows sem desinstalar toda a sua aplicação.

implantação do Xcopy. Como as dependências do SDK de Aplicações Windows são transportadas pela sua aplicação, pode implementar a sua aplicação simplesmente copiando com o comando xcopy o resultado da build, sem quaisquer requisitos adicionais de instalação.
Desvantagens Dependências de instalação adicionais. Requer a instalação do runtime do SDK de Aplicações Windows e/ou do pacote Framework, o que pode adicionar complexidade à instalação da aplicação.

Dependências compartilhadas. Risco de que as dependências compartilhadas sejam desinstaladas. Aplicativos ou usuários desinstalando os componentes compartilhados podem afetar a experiência do usuário de outros aplicativos que compartilham a dependência.

Risco de compatibilidade. Existe o risco de que as atualizações de manutenção do SDK de Aplicações Windows introduzam mudanças significativas. Embora as atualizações de manutenção devam fornecer compatibilidade com versões anteriores, é possível que regressões sejam introduzidas.		 Implantações maiores (somente aplicativos não empacotados). Como a sua aplicação inclui o SDK de Aplicações Windows, o tamanho de download e o espaço no disco rígido necessários são maiores do que seria o caso de uma versão dependente do framework.

Desempenho (somente aplicações não empacotadas). Carrega mais lentamente e utiliza mais memória, uma vez que as páginas de código não são partilhadas com outras aplicações.

Não é utilizável. A versão do SDK de Aplicações Windows distribuída com a sua aplicação só pode ser atualizada lançando uma nova versão da sua aplicação. És responsável por integrar as atualizações de manutenção do SDK de Aplicações Windows na tua aplicação.

Veja também Crie o seu primeiro projeto WinUI 3 e Use o SDK de Aplicações Windows num projeto existente.

Nota

PublishSingleFile (EXE de ficheiro único) é suportado para aplicações WinUI 3 não embaladas e autónomas (SDK de Aplicações Windows 1.5 e posteriores). As aplicações empacotadas e as aplicações dependentes da estrutura não suportam PublishSingleFile. Consulte Single-file EXE para as propriedades obrigatórias do MSBuild.

Mais informações sobre a implantação dependente do framework

Antes de configurar a sua aplicação dependente de framework para implementação, reveja a arquitetura de implementação para o SDK de Aplicações Windows para saber mais sobre as dependências que a sua aplicação tem ao usar o SDK de Aplicações Windows.

Aplicativos empacotados

Se optou por uma aplicação empacotada dependente do framework (ver Deployment overview), aqui ficam instruções sobre como implementar o tempo de execução do SDK de Aplicações Windows com a aplicação:

Empacotado com localização externa ou aplicativos não empacotados

Se optou por uma aplicação empacotada dependente do framework com localização externa, ou uma aplicação não empacotada dependente do framework (ver Deployment overview), aqui ficam instruções sobre como implementar o SDK de Aplicações Windows runtime com a app:

Mais informações sobre implantação autônoma

Consulte o guia de implementação SDK de Aplicações Windows para aplicações autónomas.

Nota

PublishSingleFile (EXE em ficheiro único) exige que a aplicação seja tanto desempacotada como autónoma. Consulte Single-file EXE para a lista completa das propriedades obrigatórias do MSBuild.

Inicializar o SDK de Aplicações Windows

A forma como deve inicializar o SDK de Aplicações Windows depende de se e como empacota a sua aplicação; e da forma como implementa em relação ao runtime do SDK de Aplicações Windows. Use a seção abaixo que se aplica ao seu aplicativo.

Aplicativos empacotados

Como seu aplicativo é implantado Como inicializar
Dependente do quadro Consulte chamar a API de implantação.
Autónomo Nenhuma inicialização necessária.

Aplicativos não empacotados e aplicativos empacotados com localização externa

Como seu aplicativo é implantado Como inicializar
Dependente do quadro Veja Usar a API do bootstrapper num aplicativo com pacote com local externo ou sem pacote.
Autónomo Consulte Optar por rejeitar (ou aceitar) o suporte automático do UndockedRegFreeWinRT.

Considerações de arquitetura (x64, ARM64)

Quando implementa a sua aplicação, deve incluir binários para cada arquitetura de processador que os seus utilizadores precisem. Isto aplica-se tanto a modos de implementação dependentes do framework como a modos de implementação autónomos.

Suporte ARM64

O Windows em dispositivos ARM (incluindo Surface Pro X, Surface Pro 11 e Copilot+ PCs) executa ARM64 nativamente. Embora a emulação x64 esteja disponível em dispositivos ARM64 com Windows 11, os binários ARM64 nativos proporcionam melhor desempenho e autonomia da bateria — e são recomendados quando se pretende a melhor experiência para cargas de trabalho de IA em dispositivos Copilot+ PCs.

Implantação nativa do ARM64

  • MSIX bundles — Crie um .msixbundle que inclua as arquiteturas x64 e ARM64. O Visual Studio gera-os automaticamente quando se constrói para várias plataformas. A Loja e o Instalador de Aplicações selecionam a arquitetura correta no momento da instalação.

  • Publicação autónoma — Especifique o identificador de tempo de execução (RID) para cada arquitetura:

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT — Construa configurações separadas para x64 e ARM64 na sua solução Visual Studio.

  • Aplicações dependentes do framework — Ao utilizar o instalador de runtime do SDK de Aplicações Windows, certifique-se de fornecer o instalador específico da arquitetura correto. O SDK de Aplicações Windows fornece instaladores separados para x64 e ARM64.

Arm64EC — migração gradual para grandes bases de código C/C++

Se a sua aplicação tiver uma grande base de código nativa (C/C++), uma recompilação completa para ARM64 pode não ser prática num único passo. O Arm64EC (Compatível com Emulação) permite misturar código x64 e ARM64 no mesmo processo. Recompilas módulos críticos de desempenho para ARM64 nativo enquanto os restantes módulos x64 correm sob emulação — tudo dentro de um único binário.

Approach Melhor para Compromisso
Recompilação completa do ARM64 Aplicações puramente .NET, pequenos projetos em C++ Melhor desempenho; requer que todas as dependências sejam compatíveis com ARM64
Arm64EC Aplicações C/C++ de grande dimensão, aplicações com plug-ins exclusivamente x64 ou DLLs de terceiros Migração incremental; as porções emuladas funcionam mais lentamente do que as nativas
Só x64 (emulado) Aplicações que não podem ser recompiladas e que não precisam de desempenho máximo O mais simples; redução da duração da bateria e maior latência em dispositivos ARM64

Para mais informações, consulte Arm64EC — Criar e portar aplicações para desempenho nativo no Arm.

Emulação (Prisma)

O Windows 11 em ARM utiliza uma camada de emulação chamada Prism para executar aplicações x64 e x86 em hardware ARM64. O Prism traduz instruções x86/x64 para ARM64 em tempo de execução, proporcionando ampla compatibilidade com aplicações sem necessidade de recompilação.

  • Emulação x64 — Disponível apenas em dispositivos Windows 11 ARM64 (não Windows 10 em ARM).
  • Emulação x86 — Disponível tanto em dispositivos Windows 10 como Windows 11 ARM64.
  • Desempenho — As aplicações emuladas normalmente correm com desempenho aceitável para cargas de trabalho de produtividade, mas aplicações que exigem muitos gráficos ou processamento de computação beneficiam significativamente de uma versão nativa ARM64 ou Arm64EC.

Tip

Se tiveres como destino apenas x64, a tua aplicação continua a ser executada em dispositivos ARM64 através da emulação Prism (apenas no Windows 11). No entanto, as versões nativas ARM64 são fortemente recomendadas para aplicações de produção — as aplicações emuladas consomem mais bateria e têm maior latência. Nos Copilot+ PCs, o ARM64 nativo pode proporcionar o melhor desempenho para cargas de trabalho de IA no dispositivo.

Para submissões na Loja, carregue pacotes específicos para cada arquitetura ou um pacote combinado que contenha ambos. A Store fornece apenas a arquitetura compatível a cada dispositivo.

  • Last updated on