File WinGet e YAML per configurare il tuo PC come un professionista

Se ogni volta che acquisti una nuova attrezzatura devi passare ore Installazione di programmi, modifica di Windows e configurazione dell'ambiente di sviluppoÈ tempo di semplificare. I file WinGet e YAML consentono di trasformare l'intero processo macchinoso in un processo praticamente automatico, che è possibile ripetere su qualsiasi PC con un singolo comando.

L'idea è di descrivere in un file di configurazione cosa si desidera installare e come dovrebbe essere configurato il sistema, e poi lasciarlo Windows Package Manager (winget) insieme a PowerShell Desired State Configuration (DSC) Fai il lavoro sporco: installa il software, applica le impostazioni, esegui gli script e controlla che la tua macchina sia nelle condizioni giuste per poter lavorare senza perdere tempo.

Che cos'è WinGet e perché è così utile per automatizzare il tuo PC?

WinGet è il gestore di pacchetti ufficiale di Microsoft per Windows 10 e Windows 11Funziona dalla riga di comando e consente di installare, aggiornare, configurare e disinstallare applicazioni in un modo molto simile a quanto avviene in GNU/Linux con apt, dnf o simili, ma perfettamente integrato nell'ecosistema Windows.

Invece di cercare programmi di installazione su centinaia di siti web, scaricare file EXE o MSI e cliccare su "Avanti, avanti, accetta", con WinGet puoi lanciare un comando come nome-pacchetto di installazione di winget e il sistema si occupa di scaricare il programma da una fonte attendibile, di eseguire l'installazione silenziosa e di registrare il pacchetto per futuri aggiornamenti.

Le principali fonti di software utilizzate da WinGet sono il Microsoft Store e il repository della community ospitato su GitHubdove ogni applicazione è descritta da un manifesto YAML che indica come installarla, la sua versione, l'hash di integrità, ecc. Inoltre, è possibile aggiungere repository privati, ad esempio uno per la tua organizzazione, per distribuire software interno in modo controllato.

L'intero ecosistema WinGet si basa su tre pilastri:

• La CLI winget (il comando che usi nel terminale).
• I servizi che ospitano e convalidano i pacchetti.
• I File di configurazione YAML che consentono di definire in modo dichiarativo lo stato desiderato di un'intera macchina, non solo di singole applicazioni.

Comandi WinGet di base per la gestione delle applicazioni

Prima di addentrarci negli aspetti tecnici dei file di configurazione YAML, è utile comprenderne le basi. comandi WinGet di base per l'uso quotidianoTutto viene gestito tramite PowerShell, Windows Terminal o il classico prompt dei comandi.

Se scrivi semplicemente Winget In una console, vedrai la versione installata, i sottocomandi disponibili e un riepilogo delle opzioni. Da lì, puoi iniziare a sperimentare senza timore.

a installa un'app Si utilizza il sottocomando install. Ad esempio, per installare Visual Studio Code sul PC, è sufficiente eseguire:

winget install Microsoft.VisualStudioCode

In questo caso, Microsoft.VisualStudioCode è l'identificatore esatto del pacchetto nel repository WinGet. In molti casi è anche possibile installare utilizzando il nome esattamente come appare nello Store, tra virgolette se contiene spazi, ma l'utilizzo dell'ID riduce l'ambiguità.

Se desideri aggiorna i tuoi programmiPuoi chiedere a WinGet di provare a caricare tutto ciò che riconosce con:

winget upgrade --all

Oppure potresti concentrarti su un'app specifica, ad esempio:

winget upgrade Microsoft.VisualStudioCode

Le versioni moderne di WinGet sono in grado di aggiornare non solo ciò che installa autonomamente, ma anche le applicazioni che rileva sul sistema e che hanno un manifesto associato nelle loro origini.

a disinstallare il softwareLa meccanica è altrettanto semplice:

winget uninstall Microsoft.VisualStudioCode

La rimozione funzionerà finché WinGet avrà il programma mappato nel suo catalogo, sia perché lo ha installato, sia perché lo riconosce tramite informazioni registrate nel sistema.

Quando hai bisogno di individuare un programma, puoi usare Ricerca WingetAd esempio, per vedere quali opzioni del blocco note sono disponibili:

winget search notepad

Il comando restituirà un elenco con nome, ID del pacchetto e origine (repository della community, Store o repository privato) e questo ID è quello che dovresti usare durante l'installazione o l'aggiornamento per sicurezza.

Se vuoi sapere quale software controlla WinGet sul tuo computer, puoi usare:

winget list

Con questo otterrai un inventario delle applicazioni rilevate dal gestore dei pacchetti. Molto utile per decidere cosa aggiornare o cosa includere nei file di configurazione.

Automazione delle installazioni con file YAML: il bello di tutto ciò

La parte davvero interessante arriva quando si passa dal digitare i comandi uno per uno a Descrivi il tuo ambiente ideale in un singolo file YAMLInvece di avere un promemoria di comandi o uno script fragile, si definisce in modo dichiarativo l'aspetto desiderato della macchina e si delega il lavoro a WinGet e DSC.

Un file di configurazione WinGet contiene l'elenco dei pacchetti, delle versioni, degli strumenti, degli script e delle impostazioni di sistema di cui hai bisogno per il tuo ambiente di sviluppo (o per l'intera azienda). Non si limita a installare programmi: può attivare funzionalità di Windows, modificare il registro, gestire servizi, avviare script di PowerShell... Tutto il necessario per mettere il PC in uno stato specifico.

Per far funzionare tutto questo, è necessario disporre di una versione sufficientemente recente di WinGet, in particolare v1.6.2631 o superioreIn questo caso, l'integrazione con DSC 3.0 e il comando winget configure, responsabile dell'elaborazione dei file di configurazione YAML, vengono introdotti in modo stabile.

Il vantaggio è che il processo diventa non presidiato e ripetibileEsegui un comando, accetti i termini e le condizioni necessari e puoi andare a prenderti un caffè mentre il sistema installa tutto il necessario, adatta Windows, configura gli IDE e prepara l'ambiente per l'uso. E se domani cambi PC, ti basta ripetere il processo e sei pronto per partire.

Inoltre, questi file possono salvalo in un repository Git, OneDrive o dove vuoi, condividi con il tuo team, modifiche alla versione, problemi aperti e richieste pull... In breve, tratta la configurazione della tua macchina come codice (IaC) e non come qualcosa di manuale e irripetibile.

Il comando winget configure e le sue opzioni principali

La porta d'accesso all'intero sistema dichiarativo è il comando configurazione winget. Si occupa di leggere il file di configurazione WinGet, verificarne la correttezza, scaricare i moduli PowerShell necessari e applicare le modifiche.

Prima di immergersi, è consigliabile abilita i componenti di configurazione (se non sono già attivi) con:

winget configure --enable

Una volta fatto questo, la cosa più sensata da fare è iniziare convalidando il file YAML con il comando:

winget configure validate -f ruta\a\archivo.winget

La convalida verifica sia il Sintassi YAML come conformità allo schema JSON configurazione ufficiale. Tieni presente che YAML è sensibile ai rientri (spazi, non tabulazioni), quindi modificare questi file in Visual Studio Code con l'estensione Red Hat YAML e lo schema WinGet collegato è quasi obbligatorio per evitare di impazzire.

Quando tutto sembra a posto, puoi Applicare seriamente le impostazioni con:

winget configure --file ruta\a\archivo.winget --accept-configuration-agreements

A quel punto, entra in gioco il processore di configurazione, che interpreta il file YAML, scarica eventuali moduli DSC mancanti dalla PowerShell Gallery e inizia a eseguire asserzioni e risorse. Le attività che lo consentono vengono eseguite in parallelo. Quelle che lo richiedono Privilegi di amministratore attiverà un avviso UAC al momento del lancio per l'elevazione.

Se preferisci fare un "test a secco" prima di apportare qualsiasi modifica, puoi usare:

winget configure test -f ruta\a\archivo.winget --accept-configuration-agreements

Con test, WinGet valuta il sistema confrontandolo con lo stato desiderato descritto nel file e Ti dice quali cose non tornano.senza nemmeno toccare la macchina. Questo è molto utile per regolare impostazioni complesse e garantire che non ci siano sorprese durante l'applicazione del file.

È anche possibile lavorare con file remoti, ad esempio ospitati in un repository pubblico o privato, eseguendo qualcosa come:

winget configure --accept-configuration-agreements --disable-interactivity -f https://tu-servidor/tu-config.winget

Questo metodo di utilizzo si adatta molto bene a scenari di distribuzione di massa o amministrazione centralizzatadove l'IT pubblica una configurazione e gli utenti o gli script devono solo eseguire un comando per lasciare il computer aziendale con lo standard definito.

Argomenti, opzioni e sottocomandi di winget configure

Il sottocomando configure supporta un numero di parametri per la messa a punto del comportamentoTra i più rilevanti ci sono:

• -f, –file. Percorso del file di configurazione WinGet da applicare.
• –percorso-modulo. Cartella locale in cui verranno archiviati i moduli DSC scaricati (per impostazione predefinita in %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules).
• –percorso-processore. Ubicazione di un processore di configurazione personalizzato, se applicabile.
• –accetta-accordi-di-configurazione. Accettare in anticipo l'avviso di configurazione per evitare una notifica interattiva.
• –sopprimi-dettagli-iniziali. Per ottenere un output più pulito, prova a nascondere i dettagli della configurazione iniziale.
• –abilita / –disabilita. Abilita o disabilita i componenti di configurazione (richiede l'accesso allo Store).
• –log, –open-log. Aprire la cartella in cui sono archiviati i registri di configurazione.
• –verbose, –verbose-logs. Consente la registrazione dettagliata per la risoluzione dei problemi.
• –nowarn, –ignore-warnings. Sopprimere i messaggi di avviso all'uscita.
• –disabilita-interattività. Impedisce qualsiasi tipo di richiesta interattiva, ideale per script non presidiati.
• –proxy / –no-proxy. Consente di definire un proxy per quella specifica esecuzione o di disabilitare l'uso di un proxy.

Oltre al comando principale, winget configure ha diversi sottocomandi Cosa vale la pena sapere:

• winget configura mostra -f . Visualizza i dettagli di uno specifico file di configurazione, utile per esaminarlo senza aprirlo in un editor.
• Elenco di configurazione di winget. Visualizza un riepilogo delle configurazioni applicate al sistema, utile per tenere traccia di ciò che è stato eseguito.
• winget configura test -f . Modalità di verifica che confronta lo stato attuale del sistema con quello definito nella configurazione.
• winget configura convalida -f . Convalida solo il file, senza toccare la macchina.
• winget configura esporta -o . Consente di esportare le risorse di configurazione in un file, indipendentemente dal fatto che si tratti di tutte le configurazioni del pacchetto (--all), un pacchetto specifico (--package-id) o una risorsa specifica (--module y --resource), aggiungendolo al file di output se già esiste.

Formato del file di configurazione WinGet e convenzione di denominazione

Utilizzo dei file di configurazione WinGet Formato YAML con schema JSON associato che definisce la struttura valida. Anche il sistema manifest di WinGet si basa su YAML. Quindi tutto rientra nello stesso modello.

Per convenzione, questi file vengono salvati con l'estensione .winget, per esempio configuration.wingetNei progetti che utilizzano Git, in genere si consiglia di archiviarli in una directory nascosta. .configlasciando percorsi come ./.config/configuration.winget per la configurazione "predefinita" del progetto.

Se il progetto utilizza diverse combinazioni di strumenti o preferenze, è possibile conservare più file di configurazione nella stessa cartella, ognuno con un nome descrittivo che indica quale ambiente utilizza (ad esempio, frontend.winget, backend.winget, Ecc.).

La prima riga del file è solitamente un commento speciale che indica agli editor quale schema JSON utilizzare. In genere ha un aspetto simile a questo:

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2

Nella direzione di base https://aka.ms/configuration-dsc-schema/ Puoi controllare la versione più recente dello schema e aggiornare il file quando Microsoft rilascia nuove revisioni con maggiori funzionalità.

Dopo tale intestazione, il nodo radice del documento è sempre proprietàche deve includere un campo configurationVersion (ad esempio 0.2.0) e le due sezioni principali che strutturano il tutto: assertions y resources.

Struttura di un file di configurazione: proprietà, asserzioni e risorse

Sotto il nodo proprietà Da un lato si dichiara che configurazioneVersioneche dovresti aumentare man mano che il file evolve, e d'altra parte le raccolte assertions y resources che descrivono il comportamento.

• sezione affermazioni. Comprende le asserzioni o le precondizioni che devono essere soddisfatte affinché determinate risorse siano significative: versione minima di Windows, presenza di una determinata funzionalità, ecc. Non sono azioni in sé, ma piuttosto controlli dell'ambiente.
• sezione risorse. Raccoglie tutte le risorse di configurazione che intendi applicare: installazioni software, impostazioni di sistema, script, gestione dei servizi, modifiche del registro, ecc. Ogni elemento in questi elenchi è rappresentato da un nodo di tipo resource con le informazioni necessarie.

In entrambi i casi, Ogni voce è definita indicando la risorsa DSC da utilizzare, con il formato {NombreModulo}/{NombreRecursoDSC}. Ad esempio, Microsoft.Windows.Settings/WindowsSettings per toccare le impostazioni di Windows, oppure Microsoft.WinGet.DSC/WinGetPackage per installare un pacchetto WinGet da DSC.

Insieme al campo delle risorse, ogni unità di solito include sezioni di direttive e impostazioni, un identificatore facoltativo id e, quando necessario, un elenco delle dipendenze dependsOn verso altre risorse o affermazioni.

Affermazioni: verificare la versione di Windows e altri prerequisiti

Le Le asserzioni agiscono come prefiltri che decidono se ha senso eseguire determinate risorse sulla macchina corrente. In questo modo, non si tenta di installare o configurare qualcosa su un sistema che non soddisfa i requisiti di base.

Un esempio tipico è il controllo del versione minima del sistema operativoMolte configurazioni richiedono almeno Windows 10 1809 o una build specifica di Windows 11, ed è inutile procedere se si utilizza una versione precedente che non supporta nemmeno WinGet.

Un'affermazione di questo stile utilizza risorse DSC come Microsoft.Windows.Developer/OsVersion, indicando una proprietà tramite le impostazioni Versione minima (ad esempio '10.0.22000') che definisce la soglia accettabile per la configurazione.

Le affermazioni possono valutare in parallelosenza un ordine rigoroso e restituiscono essenzialmente uno stato vero o falso. Se l'asserzione restituisce falso (non è soddisfatta), qualsiasi risorsa che la include come dipendenza tramite dependsOn Verrà automaticamente omesso.

Questo comportamento è considerato un risultato corretto dal punto di vista del sistema dichiarativo: è meglio saltare un blocco che non ha senso piuttosto che forzarne l'esecuzione in un ambiente non idoneo. I messaggi di output potrebbero mostrare qualcosa del tipo: "Una risorsa non è stata eseguita perché un'asserzione non è riuscita o era falsa".

Anche se alcune impostazioni non sono valide, WinGet tenterà comunque di applicarle. continuare con altre risorse indipendenti per portare il sistema il più vicino possibile allo stato desiderato. Alla fine, sarai responsabile della revisione degli errori e della decisione se modificare la configurazione o l'ambiente.

Risorse: installazione di pacchetti, modifica di Windows e avvio di script

sezione resources è il cuore pratico del file di configurazioneQui puoi elencare tutto ciò che vuoi che accada sulla macchina: installazione del software, modifiche alla configurazione del sistema, esecuzione di script PowerShell, gestione dei servizi, ecc.

Ogni risorsa è definita con un campo resource che segue la forma Modulo/RecursoDSC, per esempio Microsoft.Windows.Settings/WindowsSettings per attivare le funzioni del sistema, oppure Microsoft.WinGet.DSC/WinGetPackage per orchestrare l'installazione di un pacchetto tramite WinGet da DSC.

Facoltativamente, puoi assegnare un ID univoco che ti aiuterà a farvi riferimento da dependsOn in altre risorse. Ciò è molto utile quando si desidera, ad esempio, che la configurazione di componenti aggiuntivi di Visual Studio dipenda esplicitamente dall'installazione preventiva di Visual Studio stesso.

All'interno di ogni risorsa, la sezione le direttive contengono informazioni contestuali su come dovrebbe essere eseguito: descrizione testuale del compito (description), se i moduli di anteprima vengono accettati da PowerShell Gallery (allowPrerelease) E l' securityContext che indica se l'esecuzione richiede privilegi elevati.

Cuando pones securityContext: elevatoWinGet richiederà le autorizzazioni di amministratore una sola volta all'inizio dell'installazione e da quel momento in poi sarà in grado di eseguire risorse elevate e non elevate utilizzando processi diversi, senza bombardarti con altre finestre UAC.

sezione le impostazioni definiscono le coppie nome-valore che vengono passati alla risorsa DSC. Può essere qualcosa di semplice come DeveloperMode: true per attivare la modalità sviluppatore di Windows, o parametri più complessi come id y source da un pacchetto WinGet, il percorso di un file .vsconfig, un valore di registro specifico o i dettagli di un servizio che deve essere abilitato.

Infine, il campo dipende da Permette di dichiarare che questa risorsa debba essere eseguita solo quando determinate asserzioni o risorse precedenti sono state completate correttamente. Se una di queste dipendenze fallisce, la risorsa viene automaticamente contrassegnata come non eseguita o fallita, prevenendo effetti collaterali indesiderati.

Organizzare la sezione delle risorse in modo leggibile

Nei progetti di grandi dimensioni, i file di configurazione possono raggiungere dimensioni considerevoli, quindi vale la pena dedicare del tempo a questa operazione. Pensa un po' a come organizzi la sezione delle risorse in modo che rimanga manutenibile nel tempo.

Una strategia comune è quella di organizzare le risorse secondo un ordine logico di esecuzione:

1. Innanzitutto, ciò che il sistema prepara (asserzioni, aggiornamenti di base).
2. Poi strumenti generici (browser, compressori, utilità).
3. Poi IDE e SDK.
4. Infine, script o impostazioni più specifici.

Un altro approccio interessante è quello di raggrupparli per probabilità di fallimento o complessitàIn altre parole, bisogna mettere all'inizio le attività che più spesso si interrompono (installazioni pesanti che dipendono da una buona connessione o dalle credenziali), in modo che l'utente si accorga subito che qualcosa non va senza dover aspettare che tutto sia finito.

Molti preferiscono raggruppare per tipo di risorsaInnanzitutto, il pacchetto WinGet, poi le configurazioni di Windows (registro, funzionalità, servizi), quindi gli script e, infine, gli strumenti specifici per un particolare progetto. Questo stile spesso ricorda la struttura tipica di un progetto software e aiuta a orientarsi rapidamente.

Qualunque sia il criterio, si consiglia vivamente di accompagnare il file con un README nel repository spiegando la struttura della configurazione, le dipendenze chiave, le versioni minime di Windows richieste e i passaggi di esecuzione consigliati.

Tale documentazione fa sì che Altri sviluppatori possono contribuire all'archivio con meno rischi. per rompere qualcosa, poiché comprendono meglio cosa fa ogni blocco e quali asserzioni o dependOn sono in gioco prima di aggiungere una nuova risorsa.

Utilizzo della variabile ${WinGetConfigRoot} nei percorsi dei file

Molte risorse DSC accettano parametri che prevedono percorsi verso file specificiConfigurazioni, script, modelli, ecc. di Visual Studio. Se si utilizzano percorsi assoluti, il file perde la portabilità non appena si cambiano utenti, unità o cartelle.

Per evitare ciò, WinGet introduce la variabile ${WinGetConfigRoot}, che punta alla directory da cui stai eseguendo winget configureDa lì è possibile creare percorsi relativi che funzioneranno allo stesso modo su qualsiasi computer in cui venga rispettata la stessa struttura di cartelle.

Se, ad esempio, si salva il file di configurazione in .config/configuration.winget e il file .vsconfig Nella radice del repository, puoi usare un percorso come '${WinGetConfigRoot}\..\.vsconfig'. La parte .. Sali di un livello dalla cartella di lavoro e vai direttamente alla directory in cui si trova .vsconfig.

Questa tecnica fa sì che la stessa configurazione è valida per tutti i membri di un team che clonano il progetto in percorsi diversi, purché rispettino il posizionamento relativo dei file all'interno del repository.

Tuttavia, vale la pena ricordare nel README che L'utente deve assicurarsi che il file di destinazione esista. nel percorso relativo che prevede la configurazione prima di avviare winget configure, altrimenti l'esecuzione segnalerà errori su tali risorse.

Dove trovare i moduli DSC e le risorse pronte all'uso

Per far funzionare l'intero sistema, WinGet si basa su Moduli PowerShell che implementano le risorse DSCAlcune sono fornite "di default" dal sistema stesso (le cosiddette risorse della posta in arrivo), mentre altre si ottengono dalla PowerShell Gallery.

Tra le risorse standard hai moduli da gestire variabili di ambiente, installare o disinstallare pacchetti MSI (msiPackage), manipolare chiavi e valori del Registro di sistema (Registry), eseguire blocchi di script (Script), controllare i servizi di Windows (Service), aggiungere o rimuovere ruoli e funzionalità (WindowsFeature) o avviare e arrestare processi (WindowsProcess).

La PowerShell Gallery ospita centinaia di moduli aggiuntivi con risorse DSC fornite dalla community. Puoi utilizzare i filtri di ricerca per visualizzare solo quelle contrassegnate come "Risorsa DSC" e quindi individuare componenti riutilizzabili per le tue configurazioni.

Tuttavia, è importante tenere presente che la galleria non è un ambiente completamente controllato: Chiunque può pubblicare modulie alcuni potrebbero contenere script rischiosi o addirittura dannosi se non attentamente esaminati.

Per questo motivo, Microsoft insiste sul fatto che il origine e contenuto dei moduli prima di utilizzarli in configurazioni che verranno eseguite su macchine di produzione, soprattutto se tali risorse vengono eseguite con un contesto di sicurezza elevato.

Per vedere esempi concreti di file di configurazione, Microsoft mantiene un Repository di configurazione DSC WinGet e YAML accessibile tramite il link breve https://aka.ms/dsc.yaml, dove è possibile trovare ispirazione e utilizzare modelli già testati come base.

Sicurezza, attendibilità e criteri di gruppo relativi a WinGet

Poiché WinGet e DSC possono installare e configurare software in bloccoL'aspetto della sicurezza è fondamentale, soprattutto negli ambienti aziendali dove vigono requisiti di conformità piuttosto rigidi.

WinGet si integra con Microsoft Store tramite Origin msstore e impiega tecniche di appuntare il certificato per verificare che il certificato HTTPS dello Store corrisponda a uno dei certificati noti e quindi prevenire attacchi man-in-the-middle (MITM).

Nelle organizzazioni che utilizzano firewall con ispezione SSL, questo comportamento può causare problemi se l'appliance di sicurezza riconfeziona la connessione con il proprio certificato. In questi casi, esiste una policy chiamata BypassCertificatePinningForMicrosoftStore che consente di specificare se WinGet deve ignorare tale controllo.

Le opzioni possibili includono lasciare la policy non configurata (rispettando il comportamento predefinito consigliato), abilitandola in modo che WinGet Non convalidare il certificato dello Store oppure disattivarlo esplicitamente per forzarlo ad accettare solo i certificati Microsoft noti.

Disabilita l'ancoraggio del certificato aumenta il rischio di attacchi man-in-the-middlePertanto, questa misura dovrebbe essere adottata solo con piena cognizione di causa e, quando non vi sono alternative ragionevoli, inserendola in una strategia di sicurezza complessiva.

Oltre a questa direttiva, sono disponibili modelli di criteri di gruppo specifici di WinGet (file .admx e .adml) che consentono agli amministratori controllare le fonti consentite o bloccate, abilitare o disabilitare le funzionalità sperimentali, definire il comportamento nei confronti dei proxy e, in generale, determinano il comportamento del gestore dei pacchetti all'interno dell'organizzazione.

Questi modelli sono distribuiti all'interno del pacchetto DesktopAppInstallerPolicies.zip nel repository GitHub di WinGet. Una volta decompressi, i file vengono copiati in C:\Windows\PolicyDefinitions La cartella della lingua corrispondente è ora disponibile e può essere gestita dalla console di gestione dei criteri di gruppo.

Esistono anche oggetti di criteri di gruppo come EnableWindowsPackageManagerConfiguration e EnableWindowsPackageManagerConfigurationExplanation che consentono di bloccare l'uso dei file di configurazione WinGet nell'intera organizzazione, nel caso in cui si ritenga che questa funzionalità debba essere strettamente limitata.

Repository aggiuntivi e utilizzo di fonti private in WinGet

Di default, WinGet utilizza le seguenti fonti principali: il Microsoft Store e il repository della community su GitHubdove puoi trovare manifest per tantissimi programmi popolari: browser, suite di sviluppo, strumenti di progettazione, varie utilità, ecc.

Tuttavia, molte aziende hanno bisogno di qualcosa in più: repository privati ​​dove puoi ospitare le tue applicazioni, pacchetti interni, versioni convalidate di determinati strumenti o cataloghi filtrati conformi alle loro policy.

WinGet consente di registrare fonti aggiuntive utilizzando il comando:

winget source add --name <nombre_del_repositorio> --arg <URL_del_repositorio>

Questa origine è solitamente di tipo REST per impostazione predefinita, anche se è possibile specificarla con --type Se ne hai bisogno. Inoltre, ci sono parametri come –livello di fiducia per definire il livello di fiducia (nessuno o attendibile) e –accetta-accordi-di-fonte per accettare automaticamente i contratti di licenza sorgente, il che è essenziale quando si automatizza l'incorporazione dei repository.

Per verificare quali font hai attualmente sul tuo computer, puoi eseguire:

winget source list

Questo comando restituisce tutte le sorgenti disponibili con il loro nome e tipo. Da quel momento in poi, le ricerche e le installazioni di WinGet terranno conto dei repository aggiuntivi in ​​base alle impostazioni configurate.

Ci sono progetti che offrono Soluzioni pronte per l'implementazione per repository WinGet privati in Azure o in installazioni locali tramite Docker, che offre una notevole flessibilità nella configurazione di cataloghi aziendali o ambienti controllati in cui esiste solo software approvato dall'IT.

In pratica, la combinazione di repository privati ​​con file di configurazione YAML ben progettati consente standardizzare completamente la configurazione del software e delle apparecchiature di un'azienda, con la tranquillità che tutto proviene da un'origine che tu stesso controlli.

Con tutto quanto sopra, WinGet, i suoi file di configurazione YAML e le risorse DSC trasformano il noioso compito di preparare e mantenere i PC Windows in un processo molto più veloce, ripetibile e sicuroChe tu sia uno sviluppatore che desidera clonare il proprio ambiente su più computer o che gestisca una flotta di computer in un'organizzazione e voglia smettere di fare tutto manualmente.