如果每次添置新设备都要花费数小时时间 安装程序、调整 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 （您在终端中使用的命令）。
- MGI 托管和验证软件包的服务.
- MGI YAML配置文件 它允许您以声明的方式定义整个机器（而不仅仅是单个应用程序）的期望状态。
用于管理应用程序的基本 WinGet 命令
在深入探讨 YAML 配置文件的技术细节之前，了解一些基础知识会很有帮助。 日常使用的基本 WinGet 命令所有操作均可通过 PowerShell、Windows 终端或经典命令提示符进行管理。
如果你只是写 Winget 在控制台中，您将看到已安装的版本、可用的子命令以及选项摘要。从这里开始，您可以放心地进行各种尝试。
至 安装应用 您可以使用 install 子命令。例如，要在您的电脑上安装 Visual Studio Code，您只需执行以下操作：
winget install Microsoft.VisualStudioCode
在这种情况下， Microsoft.VisualStudioCode 是确切的包标识符 在 WinGet 存储库中。在许多情况下，您也可以直接使用商店中显示的名称进行安装（如果名称包含空格，则用引号括起来），但使用 ID 可以减少歧义。
如果quieres 更新您的程序你可以让 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 配置文件使用 YAML 格式及其关联的 JSON 模式 它定义了有效的结构。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 准备和维护工作简化为一个流程。 速度更快、可重复性更高、更安全无论您是希望在多台计算机上克隆环境的开发人员，还是希望停止手动操作组织内大量计算机的管理者，您都可以使用我们的服务。