如果每次添置新設備都要花費數小時時間 安裝程式、調整 Windows 設定以及建置開發環境是時候簡化流程了。 WinGet 和 YAML 檔案可以將整個繁瑣的過程變成幾乎全自動的流程，您只需一條命令即可在任何 PC 上重複執行。
其理念是在設定檔中描述你想要安裝的軟體以及系統應該如何配置，然後讓它自動運作。 Windows 套件管理員 (winget) 以及 PowerShell 期望狀態設定 (DSC) 完成髒活累活：安裝軟體、應用程式設定、執行腳本，並檢查您的機器是否處於合適的狀態，以便您能夠立即開始工作而不會浪費時間。
WinGet是什麼？為什麼它對實現電腦自動化如此有用？
WinGet 是微軟官方的 Windows 10 和 Windows 11 軟體套件管理器。它透過命令列運行，允許您以類似於 GNU/Linux 中使用 apt、dnf 或類似工具的方式安裝、更新、配置和卸載應用程序，但完美地整合到 Windows 生態系統中。
使用 WinGet，您無需在數百個網站上搜尋安裝程序，下載 EXE 或 MSI 檔案並點擊“下一步、下一步、接受”，只需執行以下命令即可。 winget install 包名 然後，系統從可信任來源下載程序，執行靜默安裝，並將軟體包註冊以便將來更新。
WinGet 使用的主要軟體來源有： 微軟商店和託管在 GitHub 上的社群儲存庫其中每個應用程式都由 YAML 清單進行描述，該清單指示如何安裝它、它的版本、完整性雜湊等。此外，還可以新增私人儲存庫，例如您組織的儲存庫，以便以受控的方式分發內部軟體。
整個 WinGet 生態系統是基於三大支柱：
- La CLI winget （您在終端機中使用的命令）。
- 很多 託管和驗證軟體包的服務.
- 很多 YAML設定檔 它允許您以聲明的方式定義整個機器（而不僅僅是單一應用程式）的期望狀態。
用於管理應用程式的基本 WinGet 命令
在深入探討 YAML 設定檔的技術細節之前，先了解一些基礎知識會很有幫助。 日常使用的基本 WinGet 指令所有操作均可透過 PowerShell、Windows 終端機或經典命令提示字元進行管理。
如果你只是寫 Winget 在控制台中，您將看到已安裝的版本、可用的子命令以及選項摘要。從這裡開始，您可以放心地進行各種嘗試。
至 安裝應用程序 您可以使用 install 子命令。例如，要在您的電腦上安裝 Visual Studio Code，您只需執行以下操作：
winget install Microsoft.VisualStudioCode
在這種情況下， Microsoft.VisualStudioCode 是確切的套件標識符 在 WinGet 儲存庫中。在許多情況下，您也可以直接使用商店中顯示的名稱進行安裝（如果名稱包含空格，則用引號括起來），但使用 ID 可以減少歧義。
如果你想 更新您的程式你可以讓 WinGet 嘗試上傳它所辨識到的所有內容：
winget upgrade --all
或者，您可以專注於某個特定的應用程序，例如：
winget upgrade Microsoft.VisualStudioCode
現代版本的 WinGet 不僅能夠更新它自己安裝的內容，還能更新它在系統中偵測到的、在其來源中具有關聯清單的應用程式。
至 卸載軟件其原理同樣簡單：
winget uninstall Microsoft.VisualStudioCode
只要 WinGet 的目錄中映射了該程序（無論是由於它安裝了該程序，還是由於它通過系統中註冊的信息識別出了該程序），刪除操作就會成功。
當您需要查找程式時，可以使用 Winget 搜尋例如，要查看有哪些記事本選項：
winget search notepad
該命令將返回一個列表，其中包含 名稱、包裹 ID 和來源 （社區倉庫、商店或私人倉庫），為了安全起見，在安裝或升級時應使用該 ID。
如果您想知道電腦上哪個軟體正在控制 WinGet，可以使用以下方法：
winget list
這樣你就能得到 軟體包管理器偵測到的應用程式清單。 對於決定需要更新哪些內容或在設定檔中包含哪些內容非常有用。
使用 YAML 檔案自動安裝：它的妙處就在於此
真正有趣的部分在於，當你從逐一輸入指令轉變為 請用一個 YAML 檔案描述您的理想環境與其使用命令速查表或脆弱的腳本，不如以聲明的方式定義機器的外觀，並將工作委託給 WinGet 和 DSC。
WinGet設定檔包含 軟體包、版本、工具、腳本和系統設定列表 這是您開發環境（或整個公司）所需的工具。它不僅限於安裝程式：它還可以啟動 Windows 功能、修改登錄、管理服務、啟動 PowerShell 腳本…一切將電腦置於特定狀態所需的功能。
要使此功能生效，您需要擁有足夠新版本的 WinGet，具體來說… v1.6.2631 或更高版本這時，DSC 3.0 和負責處理 YAML 設定檔的 winget configure 指令的整合才得以穩定地引入。
其優點在於該過程變得 無需人工幹預且可重複你只要執行一條指令，接受必要的協議，然後就可以去喝杯咖啡了，系統會自動安裝所有必需的軟體，調整 Windows 系統，設定你的 IDE，並準備好使用環境。如果明天你換了電腦，只要重複上述步驟即可。
此外，這些文件可以 將其儲存到 Git 倉庫、OneDrive 或任何你想要的位置。與團隊分享版本變更、未解決的問題和拉取請求…簡而言之，將機器配置視為代碼（IaC），而不是手動且不可重複的操作。
winget configure 指令及其主要選項
整個聲明式系統的入口是指令 winget 配置。 它負責讀取 WinGet 設定文件，驗證其是否正確，下載必要的 PowerShell 模組，並套用變更。
在深入研究之前，建議… 啟用設定元件 （如果尚未啟動）使用：
winget configure --enable
完成上述步驟後，最明智的做法是先使用以下指令驗證 YAML 檔案：
winget configure validate -f ruta\a\archivo.winget
驗證過程會檢查這兩方面。 YAML 語法符合 JSON 模式規範 官方配置。請注意，YAML 對縮排非常敏感（使用空格，而非製表符），因此，為了避免問題，幾乎必須使用帶有 Red Hat YAML 擴充功能和連結的 WinGet 架構的 Visual Studio Code 來編輯這些檔案。
當一切看起來都很順利時，你可以 認真應用這些設置 使用：
winget configure --file ruta\a\archivo.winget --accept-configuration-agreements
此時，配置處理器開始發揮作用，解析 YAML 文件，從 PowerShell 庫下載任何缺少的 DSC 模組，並開始執行斷言和資源。允許並行執行的任務會並行執行。那些需要並行執行的任務則會並行執行。 管理員權限 發射時會因高度問題觸發無人機警報。
如果您想在進行任何更改之前先進行“乾燥測試”，可以使用以下方法：
winget configure test -f ruta\a\archivo.winget --accept-configuration-agreements
透過測試，WinGet 會將系統狀態與文件中描述的理想狀態進行比較，從而評估系統。 它會告訴你哪些地方說不通。甚至無需觸碰機器。這對於調整複雜設定非常有用，可以確保在應用檔案時不會出現任何意外情況。
也可以處理遠端文件，例如託管在公共或私人儲存庫中的文件，方法是執行類似以下命令：
winget configure --accept-configuration-agreements --disable-interactivity -f https://tu-servidor/tu-config.winget
這種使用方法非常適合以下場景： 大規模部署或集中管理IT 部門發布配置後，使用者或腳本只需執行一個命令即可使公司電腦達到定義的標準。
winget configure 的參數、選項和子命令
configure 子命令支援多種 用於微調行為的參數其中一些最相關的內容是：
- -f，--file。 要套用的 WinGet 設定檔的路徑。
- –模組路徑。 下載的 DSC 模組將儲存在本機資料夾中（預設位於 %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules）。
- –處理器路徑。 自訂配置處理器的位置（如有）。
- –接受配置協定。 請提前接受配置警告，以避免出現互動式通知。
- –抑制初始詳細資料。 為了獲得更簡潔的輸出結果，請嘗試隱藏初始設定詳情。
- –啟用 / –停用。 啟用或停用設定元件（需要存取應用程式商店）。
- –logs，–open-logs。 打開儲存配置日誌的資料夾。
- –verbose，–verbose-logs。 啟用詳細日誌記錄功能，方便故障排除。
- –nowarn，–ignore-warnings。 退出時抑制警告訊息。
- –禁用互動性。 它能防止任何類型的互動式提示，非常適合無人值守腳本。
- –代理 / –無代理。 它允許您為該特定執行定義代理，或停用代理的使用。
除了主命令之外， winget configure 包含多個子命令 值得了解的是：
- winget configure show -f 。 顯示特定配置文件的詳細信息，方便在不打開編輯器的情況下進行檢查。
- winget 配置列表。 它會顯示已套用至系統的組態摘要，這有助於追蹤已運行的內容。
- winget configure test -f 。 驗證模式，將系統的目前狀態與組態中定義的狀態進行比較。
- winget 配置驗證 -f 。 只驗證文件，不要觸碰機器。
- winget 配置導出 -o 。 它允許將配置資源匯出到文件，無論是所有軟體包配置（
--all），一個特定的軟體包（--package-id）或特定資源（--moduley--resource），如果輸出檔案已存在，則追加到該檔案中。
WinGet設定檔格式與命名約定
WinGet 設定檔使用 具有關聯 JSON 模式的 YAML 格式 它定義了有效的結構。 WinGet 本身的清單系統也是基於 YAML。因此，所有內容都符合同一模型。
按照慣例，這些檔案在儲存時會帶有副檔名。 .winget例如 configuration.winget在使用 Git 的專案中，通常建議將它們儲存在隱藏目錄中。 .config離開路線 ./.config/configuration.winget 針對項目的「預設」配置。
如果您的專案使用不同的工具組合或首選項，您可以將多個設定檔保存在同一個資料夾中，每個檔案都有一個描述性的名稱，指示它使用的環境（例如， 前端.winget, 後端.winget等）。
文件的第一行通常是一條特殊註釋，用於告知編輯人員要使用哪個 JSON 模式。它通常看起來像這樣：
# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
沿著基部方向 https://aka.ms/configuration-dsc-schema/ 您可以查看最新的架構版本，並在微軟發布具有更多功能的新版本時更新您的檔案。
在該頭部之後，文件的根節點始終是 性能其中必須包含一個字段 configurationVersion （例如 0.2.0）以及構成所有內容的兩個主要部分： assertions y resources.
設定檔結構：屬性、斷言和資源
在節點下 性能 一方面，有人宣稱： 配置版本隨著文件的演變，你應該增加這個值；另一方面，集合… assertions y resources 描述這種行為。
- 部分 斷言。 它包含了某些資源發揮作用必須滿足的斷言或前提條件：最低 Windows 版本、特定功能的存在等。它們本身並不是操作，而是環境檢查。
- 部分 資源。 它收集了您打算應用的所有設定資源：軟體安裝、系統設定、腳本、服務管理、登錄機碼變更等等。這些清單中的每個項目都由一個類型為「節點」的節點表示。
resource並提供必要的資訊。
在這兩種情況下 每個條目都透過指明要使用的DSC資源來定義。格式 {NombreModulo}/{NombreRecursoDSC}。 例如， Microsoft.Windows.Settings/WindowsSettings 觸碰 Windows 設定，或 Microsoft.WinGet.DSC/WinGetPackage 從 DSC 安裝 WinGet 套件。
除了資源欄位外，每個單元通常還包括以下部分： 指令和設定一個可選的標識符 id 必要時，提供依賴項清單。 dependsOn 指向其他資源或主張。
斷言：檢查 Windows 版本和其他先決條件
該 斷言起到預過濾器的作用。 它會判斷在目前機器上運行某些資源是否合理。這樣，就不會嘗試在不符合基本要求的系統上安裝或設定某些東西。
一個典型的例子是檢查 最低作業系統版本許多配置至少需要 Windows 10 1809 或特定版本的 Windows 11，如果您使用的是不支援 WinGet 的舊版本，則繼續操作毫無意義。
這種風格的斷言使用了諸如 DSC 資源之類的資源。 Microsoft.Windows.Developer/OsVersion透過設定指示屬性 最小版本 （例如“10.0.22000”）定義了配置的可接受閾值。
斷言可以 平行評估沒有嚴格的順序，本質上返回真或假的狀態。如果斷言返回假（未滿足），則任何將其作為依賴項的資源都會被刪除。 dependsOn 它將被自動省略。
從聲明式系統的角度來看，這種行為被認為是正確的結果：跳過一個沒有意義的程式碼區塊比強制其在不合適的環境中執行要好得多。輸出訊息可能會顯示類似這樣的內容：“由於斷言失敗或結果為假，因此未執行某個資源。”
即使某些設定不適用，WinGet 仍會嘗試套用它們。 繼續使用其他獨立資源 使系統盡可能接近預期狀態。最後，您負責審查錯誤並決定是否更改配置或環境。
資源：安裝軟體套件、調整 Windows 系統和執行腳本
部分 資源是設定檔的核心部分。在這裡，您可以列出您希望在機器上執行的所有操作：軟體安裝、系統設定變更、執行 PowerShell 腳本、服務管理等。
每個資源都由一個欄位定義。 resource 遵循以下形式 Modulo/RecursoDSC例如 Microsoft.Windows.Settings/WindowsSettings 啟動系統功能，或 Microsoft.WinGet.DSC/WinGetPackage 透過 DSC 中的 WinGet 來協調軟體包的安裝。
（可選） 唯一識別符 這將有助於您從中引用它。 dependsOn 在其他資源中。例如，當您想要設定額外的 Visual Studio 元件時，如果 Visual Studio 本身已預先安裝，則此功能非常有用。
在每個資源中，該部分 指令包含上下文訊息 關於如何執行：任務的文字描述（description），如果接受來自 PowerShell Gallery 的預覽模組（allowPrerelease）和 securityContext 這表示執行該操作是否需要提升權限。
當你放置 securityContext: 提升WinGet 會在安裝開始時要求一次管理員權限，之後它就可以使用不同的進程來執行提升權限和非提升權限的資源，而不會彈出更多的 UAC 視窗。
部分 設定定義了名稱-值對 傳遞給 DSC 資源的資訊。它可以很簡單，例如： DeveloperMode: true 啟動 Windows 開發人員模式，或更複雜的參數，例如： id y source 從 WinGet 套件中取得 .vsconfig 檔案的路徑、特定的登錄值或需要啟用的服務的詳細資訊。
最後，該領域 取決於 它允許您聲明此資源僅在某些先前的斷言或資源成功完成後才能執行。如果其中一個依賴項失敗，則該資源會自動標記為未執行或失敗，從而防止不必要的副作用。
以易於閱讀的方式組織資源部分。
在大型專案中，設定檔可能會變得非常大，因此值得花時間進行設定。 請仔細考慮資源部分的組織方式。 這樣才能使其長期保持可維護性。
常見的策略是根據以下方式組織資源： 執行的邏輯順序:
- 首先，系統準備的內容（斷言、基本更新）。
- 然後是通用工具（瀏覽器、壓縮器、實用程式）。
- 然後是IDE和SDK。
- 最後，新增更具體的腳本或設定。
另一種有趣的方法是按以下方式對它們進行分組： 故障機率或複雜性換句話說，將最容易出錯的任務（依賴良好連接或憑證的大型安裝）放在最前面，以便用戶能夠儘早意識到出了問題，而無需等待所有任務完成。
許多人喜歡以以下方式分組 資源類型首先是 WinGet 套件，然後是 Windows 設定（登錄、功能、服務），接著是腳本，最後是特定項目的工具。這種結構通常類似於典型的軟體專案結構，有助於您快速上手。
無論採用何種標準，強烈建議將文件與以下資料一起提交： 倉庫中的 README 文件 解釋配置結構、關鍵依賴項、最低 Windows 版本要求以及建議的執行步驟。
該文檔使得… 其他開發者可以以較低的風險為該程式庫做出貢獻。 為了發現問題，他們最好先了解每個程式碼區塊的作用以及在新增資源之前有哪些斷言或依賴關係在起作用。
在檔案路徑中使用 ${WinGetConfigRoot} 變數
許多DSC資源接受預期參數 特定文件的路徑Visual Studio 設定、腳本、範本等。如果使用絕對路徑，一旦更改使用者、磁碟機或資料夾，檔案就會失去可移植性。
為了防止這種情況發生，WinGet 引入了變數 ${WinGetConfigRoot}指向您正在執行的目錄 winget configure由此，您可以建立相對路徑，這些路徑在任何遵循相同資料夾結構的電腦上都能正常運作。
例如，如果您將設定檔儲存在 .config/configuration.winget 和文件 .vsconfig 在倉庫根目錄中，您可以使用類似這樣的路徑： '${WinGetConfigRoot}\..\.vsconfig'這部分 .. 從工作資料夾向上移動一級，即可進入 .vsconfig 所在的目錄。
這項技術使得… 相同的配置對團隊的所有成員都有效。 項目可以複製到不同的路徑，只要它們遵循倉庫中文件的相對位置即可。
但是，值得注意的是，README 文件中也提到了這一點。 使用者必須確保目標檔案存在。 在啟動 winget configure 之前，需要先在相對路徑中配置，否則執行時會標記這些資源的錯誤。
哪裡可以找到DSC模組和即用型資源
整個系統的正常運作依賴於 WinGet 實作 DSC 資源的 PowerShell 模組有些是系統本身「預設」自帶的（所謂的收件匣資源），而有些則是從 PowerShell 庫中取得的。
在標準資源中，您可以找到用於管理的模組。 環境變數安裝或解除安裝 MSI 套件 (msiPackage)、操作登錄機碼和值 (Registry)、執行腳本區塊 (Script)、控制 Windows 服務 (Service)、新增或移除角色和功能 (WindowsFeature) 或啟動和停止進程 (WindowsProcess)。
La PowerShell Gallery 包含數百個其他模組 這些資源由社群貢獻，您可以使用搜尋篩選器僅顯示標記為「DSC 資源」的資源，從而找到可重複使用的元件以用於您的配置。
然而，需要注意的是，畫廊並非完全經過審計的環境： 任何人都可以發布模組如果不仔細審查，有些腳本可能包含危險或惡意程式碼。
因此，微軟堅持認為… 模組的來源和內容 在將它們用於將在生產機器上運行的配置之前，尤其是當這些資源在高安全上下文中運行時。
要查看設定檔的具體範例，微軟維護了一個 DSC WinGet 和 YAML 設定儲存庫 可透過短連結 https://aka.ms/dsc.yaml 訪問，您可以在這裡找到靈感並使用已測試的模板作為基礎。
與 WinGet 相關的安全、信任和群組策略
由於 WinGet 和 DSC 可以 大量安裝和設定軟體安全因素至關重要，尤其是在企業環境中，合規要求非常嚴格。
WinGet 透過 Origin 與 Microsoft Store 整合。 msstore 並採用以下技術 證書固定 驗證商店的 HTTPS 憑證是否與已知憑證之一匹配，從而防止中間人 (MITM) 攻擊。
在使用具有 SSL 檢測功能的防火牆的組織中，如果安全設備使用自己的憑證重新打包連接，則這種行為可能會導致問題。針對這種情況，有一種策略叫做 繞過 Microsoft Store 的憑證固定 這樣就可以指定 WinGet 是否應該跳過該檢查。
可能的選項包括：不配置該策略（遵循預設建議行為），或啟用該策略以便 WinGet 不要驗證商店證書 或明確停用它，強制它只接受已知的微軟憑證。
禁用證書錨定 增加中間人攻擊的風險因此，只有在充分了解事實且沒有其他合理替代方案的情況下，才應該這樣做，並將其納入整體安全策略中。
除了這條指令之外，還有專門針對 WinGet 的群組原則範本（.admx 和 .adml 檔案），讓管理員可以執行以下操作： 控制允許或阻止的來源，啟用或停用實驗性功能，定義對代理的行為 並且，總體上，塑造軟體包管理器在組織中的行為。
這些模板包含在軟體包中。 DesktopAppInstallerPolicies.zip 在 WinGet GitHub 儲存庫中。解壓縮後，檔案將被複製到 C:\Windows\PolicyDefinitions 相應的語言資料夾現已可用，因此可以從群組原則管理控制台進行管理。
此外，還有一些群組原則對象，例如 EnableWindowsPackageManagerConfiguration 和 EnableWindowsPackageManagerConfigurationExplanation 如果認為應該嚴格限制此功能，則可以阻止在整個組織內使用 WinGet 設定檔。
WinGet 中的其他儲存庫和私有來源的使用
WinGet 預設使用以下作為其主要資料來源： 微軟商店和GitHub上的社群儲存庫您可以在這裡找到大量流行程式的清單檔案：瀏覽器、開發套件、設計工具、各種實用程式等等。
然而，許多公司需要的遠不止這些： 私有倉庫，您可以在其中託管自己的應用程式。內部軟體包、某些工具的驗證版本或符合其策略的過濾目錄。
WinGet 允許您使用以下命令註冊其他來源：
winget source add --name <nombre_del_repositorio> --arg <URL_del_repositorio>
此來源預設通常為 REST 類型，但您也可以透過以下方式指定它： --type 如果需要的話。此外，還有一些參數，例如 信任等級 定義信任等級（無信任或完全信任） –接受來源協議 自動接受原始程式碼授權協議，這對於自動化整合儲存庫至關重要。
若要查看電腦上目前安裝了哪些字體，您可以執行：
winget source list
此命令會傳回所有可用來源及其名稱和類型。此後，WinGet 的搜尋和安裝將根據您配置的設定考慮其他儲存庫。
有些項目提供 適用於私有 WinGet 儲存庫的即用型解決方案 在 Azure 或使用 Docker 的本機安裝中，在設定企業目錄或僅存在 IT 核准軟體的受控環境時，提供了相當大的彈性。
在實務中，將私有倉庫與精心設計的 YAML 設定檔結合可以實現以下目標： 完全標準化軟體和設備配置 一家公司可以讓你安心，因為所有產品都來自你自己掌控的來源。
綜上所述，WinGet、其 YAML 設定檔和 DSC 資源將繁瑣的 Windows PC 準備和維護工作簡化為一個流程。 速度更快、可重複性更高、更安全無論您是希望在多台電腦上複製環境的開發人員，還是希望停止手動操作組織內大量電腦的管理者，您都可以使用我們的服務。