Stato corrente delle funzionalità di distribuzione delle app Windows

Questa pagina documenta lo stato corrente delle funzionalità di distribuzione delle app Windows che sono state modificate, sono note limitazioni o si comportano in modo diverso rispetto alla documentazione. Viene aggiornato man mano che la piattaforma si evolve.

Ultima revisione: Agosto 2026

Protocollo URI ms-appinstaller

Stato: disabilitato per impostazione predefinita (da dicembre 2023)

Il ms-appinstaller:?source= gestore del protocollo URI consente a una pagina Web di attivare un'installazione del programma di installazione app con un solo clic senza che l'utente scarichi prima il file. Questa funzionalità è stata disabilitata per impostazione predefinita in App Installer versione 1.21.3421.0, rilasciata il 12 dicembre 2023, in risposta al suo abuso da parte della campagna malware Emotet (CVE-2021-43890 exploit pattern).

Impacto: Le pagine dei tutorial su Microsoft Learn che illustrano i collegamenti Web non funzionano più per la maggior parte degli utenti.

Soluzioni alternative:

• Collega direttamente al .appinstaller file — gli utenti lo scaricano e fanno doppio clic. Questo funziona ancora ed è l'approccio consigliato per gli scenari non aziendali.
• Pubblica nel Microsoft Store — offre una migliore esperienza di installazione con un solo clic, senza alcuna dipendenza dal protocollo.
• Riabilitazione aziendale: Impostare i Criteri EnableMSAppInstallerProtocol di gruppo su Abilitato tramite il CSP DesktopAppInstaller. Nota: il valore Disabled del criterio indica "l'impostazione non è configurata" (doppio negativo); impostare su Enabled per riabilitare il protocollo.

Riferimenti:Funzionalità di sicurezza del programma di installazione app

Versioni dello schema dei file .appinstaller

Status: Visual Studio genera uno schema obsoleto per impostazione predefinita

Il .appinstaller file XML supporta più versioni dello schema, ognuna con funzionalità diverse. Visual Studio genera file usando lo schema 2017/2 per impostazione predefinita, che non supporta diversi attributi importanti di configurazione degli aggiornamenti.

Impact: Gli sviluppatori che si basano su Visual Studio generare file .appinstaller e quindi configurare ShowPrompt o UpdateBlocksActivation troveranno che tali impostazioni vengono ignorate automaticamente in fase di esecuzione.

Correzione: Aggiornare manualmente l'attributo xmlns nel .appinstaller file:

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

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

Riferimenti:Aggiornamento automatico e ripristino delle app · Discussione su WindowsAppSDK #5125

Reputazione di SmartScreen: i certificati EV non concedono più il bypass immediato

Stato: comportamento modificato nel 2024

Prima del 2024, i certificati di firma del codice di convalida estesa (EV) hanno concesso una reputazione SmartScreen immediata. Un file binario appena firmato non visualizza alcun avviso di download. Microsoft ha aggiornato i requisiti del programma Trusted Root nel 2024, rimuovendo gli OID specifici di EV. La reputazione di SmartScreen si accumula ora nel tempo invece di essere concessa immediatamente dal tipo di certificato. Si basa su due segnali: l'hash del file e la reputazione dell'editore del certificato di firma. Un'identità di firma coerente può trasferire la reputazione dell'editore tra i rilasci, ma nessun tipo di certificato (OV o EV) consente di aggirare immediatamente il controllo.

Impatto: Gli sviluppatori che hanno acquistato certificati EV specificamente per ignorare gli avvisi SmartScreen per le nuove versioni troveranno che i certificati EV non forniscono più questo vantaggio.

Comportamento attuale: Tutti i binari che non provengono da Store e non sono firmati da Microsoft possono mostrare un prompt di SmartScreen al primo download, finché non viene acquisita una reputazione sufficiente. La reputazione si basa sia sull’hash del file sia, per i file firmati, sul certificato del firmatario; pertanto, firmare le release con la stessa identità consente alla reputazione del certificato di mantenersi nel tempo. I file non firmati devono ricostruire la reputazione a ogni nuovo hash.

Vedi reputazione SmartScreen per sviluppatori di app Windows per informazioni dettagliate sul comportamento e le raccomandazioni previste.

MSIX in Windows 10 e Windows 11

Status: diverse funzionalità MSIX sono solo Windows 11

MSIX funziona sia su Windows 10 che su Windows 11, ma diverse funzionalità, tra cui contenitori di pacchetti condivisi, directory di pacchetti modificabili e identità persistente MSIX, sono Windows 11 solo e non sono state sottoposti a backporting. Le dipendenze dinamiche sono supportate anche in Windows 10 tramite il SDK per app di Windows (Mdd* API/bootstrapper), con Windows 11 fornendo anche un'implementazione nativa del sistema operativo. Inoltre, il supporto mainstream di Windows 10 è terminato il 14 ottobre 2025.

Per una tabella di confronto completa, le limitazioni note non retrocesse e le soluzioni alternative per ogni funzionalità, vedere MSIX in Windows 10 e Windows 11.

attività MsixPackaging@1 Azure DevOps

Stato: Utilizza dipendenze obsolete

L'attività MsixPackaging@1 nelle pipeline di Azure DevOps usa MSBuild 4.8.4161.0 (anziché MSBuild 16+) ed è stata compilata in Node 16 (che ha raggiunto la fine della vita nel settembre 2023). Ciò può causare errori di compilazione nelle configurazioni della pipeline moderne.

Workaround: Usare MSBuild direttamente nella pipeline anziché l'attività MsixPackaging@1 oppure usare GitHub Actions con l'azione microsoft/setup-msbuild.

Riferimenti:GitHub problema #518 · problema GitHub #679

Contenuti correlati

• Scegliere un percorso di distribuzione per l'app Windows
• Reputazione di SmartScreen per gli sviluppatori di app di Windows
• Panoramica del file del programma di installazione app
• Aggiornamento automatico e ripristino delle app
• Azure Firma di artefatti (in precedenza Firma attendibile)