Pubblicare la prima app Windows

È stata creata un'app macchine virtuali Windows, WinForms o WinUI 3, ora è necessario inserirla nelle mani degli utenti. Questa guida illustra il percorso completo da una compilazione completata a un'app pubblicata, che illustra i due scenari di distribuzione più comuni: la pubblicazione nella distribuzione Microsoft Store (scelta consigliata) e la configurazione di direct download.

Passaggio 1: Scegliere il percorso di distribuzione

Il percorso di distribuzione determina i costi di firma del codice, i meccanismi di aggiornamento, il modo in cui gli utenti individuano l'app e come le aziende possono distribuirla.

Scegli un percorso di distribuzione per la tua app Windows, dove è disponibile un confronto completo. In breve:

• Microsoft Store consigliato per la maggior parte delle app. Firma gratuita, aggiornamenti predefiniti, individuabilità generale e un'esperienza di installazione attendibile. Richiede un account per sviluppatore gratuito, registrarsi al storedeveloper.microsoft.com.
• Download diretto : appropriato per gli ISV commerciali con la propria vetrina, le app line-of-business aziendali o le app con contenuto non consentito dallo Store. L'utente è responsabile della firma, dell'hosting e degli aggiornamenti.

La maggior parte delle nuove app indie è una buona soluzione per lo Store. Se non sei sicuro, inizia lì.

Passaggio 2: Configurare la firma del codice

Se si sta pubblicando un pacchetto MSIX nel Microsoft Store: ignorare questo passaggio. Microsoft risigna automaticamente il tuo pacchetto come parte del processo di certificazione.

Se stai inviando un programma di installazione MSI/EXE Win32 al Microsoft Store: devi comunque firmare il programma di installazione prima dell'invio. Il programma di installazione e i relativi file PE devono essere firmati con un certificato che concatena a una CA nel Programma Microsoft Trusted Root. I certificati autofirmati non sono accettabili. Vedere Requisiti del pacchetto dell'app per MSI/EXE.

Se si distribuisce direttamente: è necessario un certificato di firma del codice attendibile. Le app non firmate e le app autofirmate attivano avvisi SmartScreen sicuri e alcuni ambienti aziendali li bloccano completamente.

Opzioni di firma del codice per sviluppatori di app Windows presentano un confronto completo. Indicazioni rapide:

• Organizzazioni in USA, Canada, UE o Regno Unito / Persone fisiche in USA o Canada:Azure Artifact Signing (in precedenza Trusted Signing) — circa $9,99/mese, senza la necessità di un token hardware, si integra con le pipeline CI/CD. Questa è l'opzione di Microsoft consigliata per la distribuzione al di fuori dello Store.
• Sviluppatori individuali al di fuori degli Stati Uniti/Canada o chiunque non sia idoneo per la Firma dell'artefatto di Azure: Un certificato OV di un'autorità di certificazione, ad esempio DigiCert o Sectigo, tra $150 e $300 all'anno.

Passaggio 3: Creare un pacchetto dell'app

La modalità di creazione del pacchetto dell'app dipende dal framework dell'app usato.

WinUI 3

Le app WinUI 3 create con i modelli di progetto SDK per app di Windows sono già confezionate come MSIX di default. Quando si compila la soluzione in Visual Studio, l'output è un file .msix o .msixbundle pronto per l'invio nello Store o la distribuzione diretta.

Se vuoi distribuire un'app WinUI 3 senza pacchetti MSIX, vedi Distribuire un'app WinUI 3 non in pacchetto. Si noti che le app WinUI 3 non in pacchetto non possono produrre un file EXE a file singolo e richiedono il runtime SDK per app di Windows nel computer dell'utente (installato separatamente tramite il programma di installazione di runtime o in bundle usando la distribuzione autonoma).

macchine virtuali Windows e WinForms

macchine virtuali Windows e i progetti WinForms non producono MSIX per impostazione predefinita. Sono disponibili diverse opzioni.

Opzione A: Progetto di Packaging dell'Applicazione Windows (MSIX)
Aggiungere un Project di creazione di pacchetti di applicazioni Windows alla soluzione in Visual Studio. Questo consente di conferire alla tua app un'identità di pacchetto MSIX, idoneità per lo Store e aggiornamenti attraverso l'App Installer. Questo è l'approccio consigliato per l'invio allo Store.

Inscatola la tua app desktop utilizzando MSIX con un progetto singolo

Opzione B: dotnet publish (EXE autonomo)
Per la distribuzione del download diretto, dotnet publish con --self-contained produce un exe autonomo che include il runtime di .NET, ovvero gli utenti non devono installare separatamente .NET.

dotnet publish -c Release -r win-x64 --self-contained true

Ciò produce una cartella di file adatti per la compressione e distribuzione o incapsulare in un programma di installazione. Non è direttamente idoneo per lo Store.

Opzione C: Pubblicazione dipendente dal framework
Omettere --self-contained se si ha familiarità con la richiesta agli utenti di avere installato il runtime di .NET corretto. L'output è più piccolo ma ha una dipendenza di runtime.

Passaggio 4a: Inviare al Microsoft Store (percorso consigliato)

Il processo di invio allo Store viene eseguito tramite il Centro per i partner.

Passaggi a colpo d'occhio:

1. Creare un account per sviluppatore : gratuito. Registrarsi al storedeveloper.microsoft.com. L'account è permanente.
2. Riservare il nome dell'app : richiedi il nome della tua app nel Centro per i partner prima dell'invio. Il nome è riservato per te durante lo sviluppo.
3. Compilare e creare un pacchetto dell'app : creare un pacchetto MSIX che soddisfi i requisiti dello Store. Per gli invii nello Store, i pacchetti MSIX/AppX non necessitano di una firma attendibile CA; Microsoft risigna il pacchetto con un certificato Microsoft dopo la certificazione. Se si distribuisce all'esterno dello Store usando un programma di installazione MSI o EXE, la firma Authenticode è consigliata ed è prevista dalle funzionalità di sicurezza di Windows.
4. Crea l'invio : carica il pacchetto, fornisci i dettagli della presentazione nello Store (descrizione, screenshot, categorie, fascia d'età) e imposta i prezzi.
5. Certification: Microsoft esamina l'app per la conformità dei criteri. La certificazione richiede in genere alcuni giorni lavorativi per le nuove app.
6. Pubblica : dopo la certificazione, l'app viene visualizzata nello Store ed è disponibile per gli utenti.

→ Creare l'invio dell'app
requisiti del pacchetto dell'app →

Passaggio 4b: Distribuire direttamente (percorso alternativo)

Se stai distribuendo la tua app all'esterno dello Store, hai diverse opzioni di creazione di pacchetti e hosting.

MSIX con il programma di installazione app (.appinstaller)

I pacchetti MSIX distribuiti con un file complementare .appinstaller supportano i controlli di aggiornamento automatico. Quando gli utenti installano l'app dal file .appinstaller, Windows controlla periodicamente l'URL che hai specificato per una versione più recente e propone di aggiornare.

ClickOnce (macchine virtuali Windows e WinForms)

ClickOnce è una tecnologia di distribuzione .NET integrata in Visual Studio che supporta gli aggiornamenti automatici per le app macchine virtuali Windows e WinForms. Gli utenti installano da un manifesto ospitato e ClickOnce gestisce i controlli di aggiornamento in modo trasparente.

ClickOnce non è supportato per le app WinUI 3 : usare MSIX con .appinstaller .

→ la sicurezza e la distribuzione clickOnce

Programma di installazione EXE

Un programma di installazione EXE tradizionale creato con uno strumento come WiX Toolset o Inno Setup è familiare agli utenti e semplice da produrre. Questi sono strumenti di community ben consolidati usati da molte applicazioni Windows. Si noti che i programmi di installazione EXE richiedono di implementare il proprio meccanismo di aggiornamento.

Hosting del download

Opzioni di hosting comuni per il download diretto:

• GitHub Releases , gratuito, con versione e si integra bene con le pipeline di compilazione automatizzate. Adatto per app commerciali open source e di piccole dimensioni.
• Il tuo sito Web : controllo completo sulla pagina di download, sull'analisi e sul flusso di pagamento. Se l'app aumenta, sarà necessaria una capacità di archiviazione e rete CDN affidabile.
• Negozi di terze parti : alcuni sviluppatori distribuiscono tramite vetrine, ad esempio itch.io per le app adiacenti al gioco.

winget per la visibilità

L'invio dell'app al repository community Windows Gestione pacchetti rende l'app installabile tramite winget install. Questo è particolarmente apprezzato dagli sviluppatori e dai gruppi di destinatari power-user che preferiscono gli strumenti da riga di comando. L'invio è un pull request al repository del manifesto della comunità ed è gratuito.

Passaggio 5: Configurare l'aggiornamento automatico

Mantenere gli utenti nella versione più recente riduce il carico di supporto e garantisce che le correzioni di sicurezza vengano soddisfatte tempestivamente.

Per le distribuzioni EXE o autonome senza un meccanismo di aggiornamento predefinito, Velopack è uno strumento della community che aggiunge funzionalità di aggiornamento automatico e programma di installazione alle app .NET. Non è un prodotto Microsoft , valutarlo in base ai propri requisiti.

Passaggio 6: Gestire SmartScreen per le nuove app

Ogni nuova app, indipendentemente da quanto bene sia firmata, attiverà un avviso SmartScreen al primo download fino a quando non accumulerà una cronologia di download sufficiente. Questo è previsto e normale. Ecco come gestirlo bene:

• Firmare ogni rilascio. Le app non firmate mostrano un blocco più severo con il messaggio "Windows ha protetto il tuo PC". Le app firmate mostrano un avviso "app non riconosciuta" più flessibile che gli utenti possono ignorare più facilmente.
• Impostare le aspettative con gli utenti iniziali. Indicare ai beta tester e agli early adopter cosa aspettarsi. Una breve nota nell'annuncio di rilascio ("È possibile che venga visualizzato un prompt di SmartScreen al primo esecuzione: questo è normale per le nuove app; Fare clic su 'Altre informazioni' e quindi su 'Esegui comunque'") impedisce confusione e installazioni abbandonate.
• Siate pazienti. La reputazione si basa organicamente con il volume di download. Non esiste alcun processo di invio manuale per accelerarlo per gli endpoint destinati ai consumatori.

Reputazione di SmartScreen per gli sviluppatori illustra il modello di reputazione completo, cosa gli utenti vedono in ogni fase, e le considerazioni sui criteri aziendali.

Cosa succederà dopo

Dopo la pubblicazione dell'app, puoi:

• Monitorare l'integrità e le classificazioni delle app — il Centro per i partner offre analisi degli arresti anomali, valutazioni degli utenti e gestione delle revisioni per le app dello Store
• Gestire le versioni con implementazioni a fasi : lo Store supporta l'implementazione di una nuova versione a una percentuale di utenti prima di una versione completa
• Impostare i dati di telemetria: è consigliabile integrare un servizio di analisi di utilizzo e arresto anomalo del sistema, ad esempio applicazione Azure Insights o un altro SDK di analisi per comprendere come viene usata l'app
• Rispondi al feedback degli utenti — Il Centro per i partner espone le recensioni dello Store; per le app di download diretto, prendere in considerazione un canale di feedback (GitHub Issues, un indirizzo di posta elettronica dedicato o un forum della community)

Contenuti correlati

• Scegliere un percorso di distribuzione per l'app Windows
• opzioni di firma di Code per sviluppatori di app Windows
• Reputazione di SmartScreen per sviluppatori
• Stato corrente delle funzionalità di distribuzione
• Creare l'invio dell'app
• Azure Firma di artefatti (in precedenza Firma attendibile)
• Windows Gestione pacchetti (winget)