Partilhar via


Estado atual das funcionalidades de distribuição de aplicações Windows

Esta página documenta o estado atual das funcionalidades de distribuição de aplicações Windows que mudaram, são conhecidas por terem limitações ou comportam-se de forma diferente do que a sua documentação sugere. É atualizado à medida que a plataforma evolui.

Última análise: Abril de 2026


Protocolo URI ms-appinstaller

Estado: Desativado por defeito (desde dezembro de 2023)

O ms-appinstaller:?source= handler do protocolo URI permite que uma página web desencadeie uma instalação do App Installer com um clique sem que o utilizador descarregue primeiro o ficheiro. Esta funcionalidade foi desativada por defeito na versão 1.21.3421.0 do App Installer, lançada a 12 de dezembro de 2023, em resposta ao seu abuso pela campanha de malware Emotet (padrão de exploração CVE-2021-43890).

Contexto Situação
Dispositivos de consumo (padrão) ❌ Desativado
Dispositivos empresariais (geridos por TI) ✅ Pode ser reativado através da Política de Grupo

Impacto: Páginas tutoriais no Microsoft Learn, que apresentam <a href="ms-appinstaller:?source=...">Install</a> ligações web, já não funcionam para a maioria dos utilizadores.

Soluções alternativas:

  • Liga diretamente ao .appinstaller ficheiro — os utilizadores descarregam e fazem duplo clic. Isto ainda funciona e é a abordagem recomendada para cenários não empresariais.
  • Publish to the Microsoft Store — oferece uma experiência de instalação superior com um clique, sem dependência de protocolo.
  • Reativação empresarial: Defina a EnableMSAppInstallerProtocol Política de Grupo como Ativada através do CSP DesktopAppInstaller. Nota: o valor Disabled da política significa "a definição não está configurada" (duplo negativo); defina como Enabled para reativar o protocolo.

Referências:Funcionalidades de segurança do instalador de aplicações


Versões do esquema de ficheiros .appinstaller

Status: Visual Studio gera esquema desatualizado por defeito

O ficheiro .appinstaller XML suporta múltiplas versões de esquema, cada uma com capacidades diferentes. Visual Studio gera ficheiros usando o esquema 2017/2 por defeito, que não suporta vários atributos importantes de configuração de atualização.

Attribute Esquema 2017/2 Esquema de 2021
ShowPrompt ❌ Não suportado ✅ Suportado
UpdateBlocksActivation ❌ Não suportado ✅ Suportado
HoursBetweenUpdateChecks ❌ Não suportado ✅ Suportado
Atualização essencial sobre o lançamento ✅ Suportado ✅ Suportado

Impact: Os programadores que dependem do Visual Studio para gerar ficheiros .appinstaller e depois configurar ShowPrompt ou UpdateBlocksActivation vão perceber que essas definições são silenciosamente ignoradas em tempo de execução.

Correção: Atualize manualmente o xmlns atributo no seu .appinstaller ficheiro:

<!-- Change this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2" ...>

<!-- To this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2021" ...>

Referências:Aplicações de atualização automática e reparação · Discussão sobre WindowsAppSDK #5125


Reputação do SmartScreen: Os certificados de veículos elétricos já não concedem bypass instantâneo

Estado: Comportamento alterado em 2024

Antes de 2024, os certificados de assinatura de código de Validação Estendida (EV) concediam reputação SmartScreen imediata — um binário recém-assinado não apresentava qualquer aviso de download. A Microsoft atualizou os requisitos do Programa Raiz Confiável em 2024, removendo os OIDs específicos para veículos elétricos. A reputação do SmartScreen é agora exclusivamente baseada em hash e acumula-se ao longo do tempo, independentemente do tipo de certificado (OV ou EV).

Impacto: Os desenvolvedores que compraram certificados de VE especificamente para contornar os avisos do SmartScreen em novos lançamentos irão descobrir que os certificados de VE já não proporcionam este benefício.

Comportamento atual: Todos os binários que não são da Store nem assinados pela Microsoft mostram um aviso SmartScreen no primeiro download até que haja histórico de downloads suficiente acumulado para esse hash de ficheiro.

Consulte a reputação SmartScreen para desenvolvedores de aplicações Windows para detalhes completos sobre comportamento esperado e recomendações.


MSIX em Windows 10 vs Windows 11

Status: Várias funcionalidades do MSIX são exclusivas do Windows 11

O MSIX funciona tanto no Windows 10 como no Windows 11, mas várias funcionalidades — incluindo contentores partilhados de paquetes, diretórios de pacotes mutáveis e identidade persistente do MSIX — são apenas para o Windows 11 e não foram retroportadas. Dependências dinâmicas também são suportadas no Windows 10 através do SDK de Aplicações Windows (APIs Mdd* / bootstrapper), e o Windows 11 fornece adicionalmente uma implementação nativa do sistema operativo. Além disso, o suporte mainstream do Windows 10 terminou a 14 de outubro de 2025.

Para uma tabela de comparação completa, limitações conhecidas não retroportadas e soluções alternativas por funcionalidade, consulte MSIX no Windows 10 e Windows 11.


MsixPackaging@1 Azure DevOps tarefa

Estado: Utiliza dependências desatualizadas

A tarefa MsixPackaging@1 nos pipelines do Azure DevOps utiliza o MSBuild 4.8.4161.0 (em vez do MSBuild 16+) e foi desenvolvida para o Node 16 (que atingiu o fim da vida útil em setembro de 2023). Isto pode causar falhas na compilação em configurações modernas de pipeline.

Solução alternativa: Use o MSBuild diretamente no seu pipeline em vez da tarefa MsixPackaging@1, ou use GitHub Actions com a ação microsoft/setup-msbuild.

Referências:GitHub Edição #518 · GitHub Edição #679