Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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: Agosto 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
.appinstallerficheiro — 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
EnableMSAppInstallerProtocolPolítica de Grupo como Ativada através do CSP DesktopAppInstaller. Nota: o valorDisabledda política significa "a definição não está configurada" (duplo negativo); defina comoEnabledpara 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 acumula-se agora ao longo do tempo , em vez de ser concedida instantaneamente pelo tipo de certificado. Baseia-se em dois sinais: o hash do ficheiro e a reputação do editor do certificado de assinatura. Uma identidade de assinatura consistente pode manter a reputação do editor entre os lançamentos, mas nenhum tipo de certificado (OV ou EV) concede um bypass imediato.
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 sejam da Store e que não estejam assinados pela Microsoft podem apresentar um aviso do SmartScreen na primeira transferência, até adquirirem reputação suficiente. A reputação é construída tanto a partir do hash do ficheiro como, no caso de ficheiros assinados, do certificado do publicador, pelo que assinar as versões com a mesma identidade permite que a reputação do certificado transite para versões futuras. Os ficheiros não assinados têm de restabelecer a reputação para cada novo hash.
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
Conteúdo relacionado
Windows developer