Compartilhar via

Status atual dos recursos de distribuição de aplicativos Windows

Esta página documenta o status atual de Windows recursos de distribuição de aplicativos que foram alterados, são conhecidos por ter limitações ou se comportam de forma diferente do que a documentação pode sugerir. Ele é atualizado à medida que a plataforma evolui.

Última análise: Abril de 2026

Protocolo URI ms-appinstaller

Status: Desabilitado por padrão (desde dezembro de 2023)

O ms-appinstaller:?source= manipulador de protocolo URI permite que uma página da Web dispare uma instalação do Instalador de Aplicativo com um clique sem que o usuário baixe o arquivo primeiro. Esse recurso foi desabilitado por padrão no Instalador de Aplicativos versão 1.21.3421.0, lançado em 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 consumidor (padrão) ❌ Desativado
Dispositivos empresariais (gerenciados por TI) ✅ Pode ser habilitado novamente por meio da Política de Grupo

Impacto: Páginas de tutorial no Microsoft Learn que demonstram <a href="ms-appinstaller:?source=...">Install</a> links da web não funcionam mais para a maioria dos usuários.

Soluções alternativas:

  • Vincular diretamente ao .appinstaller arquivo – os usuários baixam e clicam duas vezes nele. Isso ainda funciona e é a abordagem recomendada para cenários não empresariais.
  • Publish para o Microsoft Store — fornece uma experiência superior de instalação com um clique, sem dependência de protocolo.
  • Reabilitação da empresa: Defina a EnableMSAppInstallerProtocol Política de Grupo como Habilitada por meio do DesktopAppInstaller CSP. Observação: o valor Disabled da política significa "a configuração não está configurada" (negação dupla); defina para Enabled para habilitar novamente o protocolo.

Referências:recursos de segurança do App Installer

Versões de esquema de arquivo .appinstaller

Status: Visual Studio gera esquema desatualizado por padrão

O .appinstaller arquivo XML dá suporte a várias versões de esquema, cada uma com funcionalidades diferentes. Visual Studio gera arquivos usando o esquema 2017/2 por padrão, que não dá suporte a vários atributos de configuração de atualização importantes.

Attribute Esquema 2017/2 Esquema de 2021
ShowPrompt ❌ Sem suporte ✅ Com suporte
UpdateBlocksActivation ❌ Sem suporte ✅ Com suporte
HoursBetweenUpdateChecks ❌ Sem suporte ✅ Com suporte
Atualização básica na inicialização ✅ Com suporte ✅ Com suporte

Impact: Desenvolvedores que dependem de Visual Studio para gerar arquivos .appinstaller e, em seguida, configurar ShowPrompt ou UpdateBlocksActivation descobrirão que essas configurações são silenciosamente ignoradas no runtime.

Corrigir: Atualize manualmente o xmlns atributo em seu .appinstaller arquivo:

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

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

References:Aplicativos de atualização automática e reparação · Discussão do WindowsAppSDK nº 5125

Reputação do SmartScreen: certificados EV não concedem mais passagem instantânea

Status: Comportamento alterado em 2024

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

Impacto: Os desenvolvedores que compraram certificados EV especificamente para ignorar os avisos do SmartScreen para novas versões descobrirão que os certificados EV não fornecem mais esse benefício.

Comportamento atual: Todos os binários que não pertencem à Store e não são assinados pela Microsoft mostram um prompt do SmartScreen no primeiro download, até que haja histórico de download suficiente acumulado para o hash desse arquivo.

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

MSIX no Windows 10 versus Windows 11

Status: vários recursos MSIX são exclusivos para Windows 11

MSIX funciona tanto no Windows 10 quanto no Windows 11, mas vários recursos, incluindo contêineres de pacotes compartilhados, diretórios de pacotes mutáveis e identidade persistente do MSIX, são exclusivos do Windows 11 e não foram retrocompatibilizados. Também há suporte para dependências dinâmicas no Windows 10 por meio do SDK do Aplicativo Windows (Mdd* APIs / bootstrapper), com o Windows 11 fornecendo adicionalmente uma implementação nativa do sistema operacional. Além disso, Windows 10 suporte principal terminou em 14 de outubro de 2025.

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

tarefa MsixPackaging@1 do Azure DevOps

Status: usa dependências desatualizadas

A tarefa MsixPackaging@1 nos pipelines do Azure DevOps usa o MSBuild 4.8.4161.0 (em vez do MSBuild 16+) e foi construída com o Node 16 (que atingiu o fim da vida útil em setembro de 2023). Isso pode causar falhas de build em configurações de pipeline modernas.

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

References:GitHub Issue #518 { GitHub Issue #679

Conteúdo relacionado

  • Last updated on