Windows 11 nasconde una nuova Store CLI per installare le app Microsoft Store. Non bastava winget?

Con Windows 11, Microsoft ha introdotto in modo silenzioso ma significativo una nuova Store CLI, ovvero un’interfaccia a riga di comando dedicata esclusivamente alla gestione delle applicazioni del Microsoft Store. Questa scelta ha immediatamente sollevato una domanda cruciale tra amministratori di sistema, sviluppatori e power user: perché creare una nuova CLI quando winget esiste già ed è perfettamente in grado di installare app dello Store, incluse quelle Microsoft?

Winget: orchestrazione dell’installazione

Winget nasce come Windows Package Manager, ma il termine “package manager” non va inteso in senso stretto. Non governa un ecosistema coerente di pacchetti costruiti secondo regole comuni; piuttosto, orchestra processi di installazione eterogenei basandosi su manifesti dichiarativi.

Quando winget installa un’applicazione del Microsoft Store, non diventa proprietario del processo. Si limita ad attivare un’operazione demandata allo Store stesso, senza assumere alcuna responsabilità sullo stato applicativo, sulle licenze o sul ciclo di vita commerciale dell’app. L’approccio è coerente con il suo obiettivo primario: automatizzare il provisioning di software su Windows, indipendentemente dalla sorgente.

Dal punto di vista tecnico, winget non conosce il concetto di “app acquistata”, non gestisce entitlements e non è in grado di riflettere in modo completo lo stato reale del Microsoft Store. Questa neutralità è il suo punto di forza in ambito enterprise e DevOps, ma è anche il motivo per cui winget non può diventare l’interfaccia ufficiale da riga di comando dello Store.

Store CLI (store): un frontend diretto del Microsoft Store su Windows 11

La Store CLI introdotta in Windows 11 con il comando store opera su un piano completamente diverso. Non è un orchestratore e non è generalista. È un client diretto del Microsoft Store, progettato per interagire esclusivamente con le applicazioni distribuite tramite quello specifico canale.

Provate in Windows 11 ad aprire un prompt dei comandi (cmd) o una finestra PowerShell e a digitare store.

Tecnicamente, la Store CLI è legata al runtime di Windows. Dialoga con i servizi locali dello Store, accede ai metadati completi delle applicazioni e riflette lo stato reale del marketplace, inclusa la distinzione tra app gratuite e a pagamento. Si tratta di un aspetto fondamentale: a differenza di winget, la Store CLI lavora all’interno del perimetro commerciale e transazionale dello Store.

Proprio per questa ragione, la Store CLI non è e non può essere cross-platform. Il suo scopo non è astrarre il sistema, ma esporre in forma testuale le funzionalità di uno store che esiste solo su Windows. Da un punto di vista architetturale, è più simile a un frontend alternativo dell’app Microsoft Store che a un package manager tradizionale.

Va sottolineato però che, allo stato attuale, la Store CLI appare come uno strumento ancora sperimentale: privo di una documentazione ufficiale strutturata, non integrato nei flussi enterprise e non chiaramente posizionato nella strategia di lungo periodo di Microsoft.

msstore: perché è uno strumento per sviluppatori, non per utenti

Incredibilmente, se non vi bastassero le interfacce a riga di comando per l’installazione di software, esiste anche la Microsoft Store Developer CLI, invocata con il comando msstore. Può essere installata (ed è un po’ un paradosso), con winget:

winget install Microsoft.DotNet.DesktopRuntime.8
winget install "Microsoft Store Developer CLI"

Rispetto alla Store CLI di Windows 11, msstore appartiene a un altro livello dello stack. Non gestisce applicazioni installate sul sistema; non installa, non aggiorna e non interroga il Microsoft Store locale. È un client per le API del Microsoft Partner Center (piattaforma centrale attraverso cui sviluppatori e aziende gestiscono la distribuzione commerciale dei propri prodotti all’interno dell’ecosistema Microsoft), progettato per automatizzare le attività di pubblicazione, packaging e submission delle applicazioni.

Il fatto che msstore sia disponibile su Windows, Linux e macOS non è un dettaglio secondario, ma una conseguenza diretta della sua funzione. Operando esclusivamente sul backend del marketplace, msstore non ha bisogno di un sistema Windows né di un runtime applicativo. Deve solo autenticarsi tramite Microsoft Entra ID e interagire con i servizi cloud del Microsoft Store.

Le sue capacità – inizializzazione dei progetti, creazione di pacchetti MSIX, gestione degli invii sul Microsoft Store, pubblicazione e integrazione in pipeline CI/CD – sono chiaramente orientate allo sviluppo e alla distribuzione, non al consumo delle applicazioni. Per questo motivo msstore è, a tutti gli effetti, uno strumento per sviluppatori e publisher, non per utenti avanzati o amministratori di sistema.

Il fatto che la Developer CLI si installi tramite winget rafforza ulteriormente questa separazione dei ruoli: winget agisce come meccanismo di distribuzione, mentre msstore opera come strumento specializzato su un dominio ben definito.

Conclusione

È vero che winget, Store CLI e msstore rispondono a esigenze diverse e operano su livelli distinti dello stack. Non c’è una sovrapposizione funzionale diretta e, a livello puramente tecnico, ciascuno degli strumenti è coerente con il proprio dominio. In questo senso, winget non è stato trascurato e la Store CLI non ne rappresenta un’evoluzione naturale, così come msstore rimane correttamente confinato al mondo della pubblicazione e del Partner Center.

Tuttavia, questa frammentazione introduce un problema reale: la moltiplicazione delle interfacce senza un modello dichiarato. Dal punto di vista dell’utente avanzato e dell’amministratore di sistema, la distinzione tra “automatizzare”, “interagire” e “pubblicare” non è sempre evidente, soprattutto quando tutti gli strumenti gravitano attorno allo stesso ecosistema, il Microsoft Store.

La domanda se non sarebbe stato sufficiente integrare le funzionalità dello Store direttamente in winget è quindi legittima. Tecnicamente, un’integrazione più profonda sarebbe possibile, ma richiederebbe di trasformare winget da orchestratore neutrale a client di piattaforma, compromettendo alcune delle caratteristiche che lo rendono utile in ambito enterprise e di automazione. La scelta di separare gli strumenti evita questo snaturamento, ma sposta la complessità sull’utente.

Finché Microsoft non chiarirà quale interfaccia rappresenti il punto di accesso “canonico” allo Store per l’utenza tecnica, la convivenza tra winget, Store CLI e msstore resterà funzionale ma ambigua.