Selenium .NET Bindings 构建指南基于 Bazel 的 hermetic 构建与 Paket 依赖管理【免费下载链接】seleniumA browser automation framework and ecosystem.项目地址: https://gitcode.com/GitHub_Trending/se/selenium本指南以 Selenium 仓库中 dotnet/README.md 为核心脉络系统讲解 .NET Bindings 的开发工作流如何用 Bazel 构建整个dotnet模块、如何用 Paket 管理 NuGet 依赖、以及如何把一次依赖升级安全地同步进 Bazel 构建系统。读完本文你将掌握在 macOS、Linux 与 Windows 上搭建 Selenium .NET 开发环境的完整操作序列并理解构建链路背后各配置文件与 Bazel 规则的真实作用。为什么 .NET Bindings 也要用 Bazel 构建Selenium 是一个横跨 Java、Python、JavaScript、Ruby、Rust、C 与 .NET 的巨型 monorepo各语言模块共享大量 WebDriver 协议、BiDi schema 与浏览器驱动资源。为了给所有语言绑定提供一致的、可复现的构建体验仓库在根目录通过WORKSPACE、MODULE.bazel采用 Bazel 作为统一构建系统.NET 模块也不例外。正如 dotnet/README.md 所述Just as in the rest of the project, we use Bazel as our build system.Bazel 带来的核心收益是hermetic密封式构建环境构建所需的 .NET SDK、工具链、第三方依赖乃至浏览器驱动版本都由 Bazel 统一下载并固定开发者不必操心本机环境的差异。这意味着同一个构建脚本在 macOS 和 Linux以及 Windows上都能产出可预期的结果。当然这也带来一个小小的代价工作流与纯dotnet build的常规习惯略有不同——在打开 Visual Studio / Rider 工程之前必须先让 Bazel 把一切需要的产物构建出来。用 Bazel 构建 .NET Bindings 全量产物在仓库根目录存在WORKSPACE文件的那一层执行bazel build dotnet/...几点使用须知首次构建耗时较长Bazel 会下载一批必要的工具链文件与外部依赖请保证网络连接通畅目标前缀dotnet/...表示构建dotnet目录下的所有Bazel target该命令同时适用于 Windows / macOS / Linux但 Windows 上对 shell 与路径有一定要求Bazel 会自动选择对应平台的 dotnet 运行时。一层层看 BUILD.bazel 暴露了哪些目标dotnet/BUILD.bazel 是模块入口它组合了若干自定义规则这些规则由 dotnet/defs.bzl 统一 re-exportBazel Target作用//dotnet:release用pkg_zip将support-pack与webdriver-pack两个 NuGet 包打成一个 release zip用于发布产物归档//dotnet:docs调用docfx规则以 docs/docfx.json 为配置生成 API 文档站点//dotnet:publishnuget_push规则把webdriver-pack与support-pack推送到 NuGet 源//dotnet:paket-update///dotnet:paket-install在 Bazel 管理之下运行 Paket 的update/install命令见后文//dotnet:formatdotnet_format规则对模块代码执行格式校验/格式化bazel build dotnet/...会把上述可构建的部分全部编译包括 dotnet/src/webdriver核心 API与 dotnet/src/supportSupport/UI 支持库。编译后的每个 .NET 程序集还会写入由AssemblyInfo.cs.template与Selenium.snk强命名密钥生成的版本信息。版本与目标框架从哪来与各语言模块一致.NET 模块的版本集中定义在 dotnet/version.bzlSE_VERSION 4.49.0-nightly202608272014 SUPPORTED_DEVTOOLS_VERSIONS [ v152, v150, v151, ]它同时声明了当前支持的 Chrome DevTools Protocol 版本v150–v152dotnet/defs.bzl 中的devtools_version_targets()会据此生成//dotnet/src/webdriver/DevTools:generate-{version}代码生成目标。此外工具链注册由 dotnet/workspace.bzl 中的selenium_register_dotnet()完成——它调用d2l_rules_csharp的csharp_register_toolchains()与csharp_repositories()将 Bazel 托管的 C# 编译工具链接入构建。用 Paket 管理 NuGet 依赖.NET 模块不使用 Visual Studio 默认的PackageReference隐式还原而是依赖Paket这一 .NET 生态的依赖管理工具将依赖关系显式收口在少数几个声明文件中并能与 Bazel 的 hermetic 仓库无缝衔接。仓库中已存在的证据包括 dotnet/paket.dependencies依赖声明、dotnet/paket.lock版本锁定以及供 Bazel 解析的 dotnet/paket.nuget.bzl。一次性安装 Paket 本地工具按 dotnet/README.md 的指引先进入dotnet目录并初始化 .NET 本地工具清单dotnet new tool-manifest dotnet tool install paket dotnet tool restoredotnet new tool-manifest会在当前目录生成.config/dotnet-tools.json本地工具清单dotnet tool install paket将 Paket 以tool manifest 方式固定到该清单dotnet tool restore按清单下载并恢复本地工具。这是一次性步骤。仓库已提交了 dotnet/.config/dotnet-tools.json其中固定了{ tools: { paket: { version: 10.3.1, commands: [paket], rollForward: false }, aver: { version: 1.0.2, commands: [aver], rollForward: false } } }即本仓库使用 Paket10.3.1rollForward: false禁止未来版本静默替代并附带一个aver工具用于程序集版本相关处理。paket.dependencies依赖声明文件的构成dotnet/paket.dependencies 是 Paket 的唯一事实来源其头部是全局配置group nuget framework: net462,net8.0,netstandard2.0 strategy: min source https://api.nuget.org/v3/index.jsongroup nuget依赖分组名Bazel 侧也据此命名解析出来的 NuGet 仓库framework: net462,net8.0,netstandard2.0同时为 .NET Framework 4.6.2、.NET 8.0 与netstandard2.0三个目标框架解析依赖——这解释了为何 .NET Bindings 能同时服务经典 .NET Framework 与新版 .NETstrategy: min安装时倾向解析到满足约束的最低版本保证锁定文件确定性source官方 NuGet 源地址。其下则是实际依赖清单主要可分为三类用途核心运行时依赖如System.Collections.Immutable、System.Text.Json、System.Threading.Channels8.x 系列支撑 WebDriver 的 JSON 序列化、并发通道等基础能力测试与构建期依赖NUnit 4.6.0、NUnit3TestAdapter、NUnit.Analyzers、Moq 4.20.72、Microsoft.Testing.Platform、Microsoft.Testing.Extensions.VSTestBridge、Microsoft.Extensions.DependencyInjection、NETStandard.Library辅助工具依赖CommandLineParser命令行参数解析、Handlebars.Net生成 DevTools/BiDi 代码模板、Humanizer.Core、RunfilesBazel runfiles 定位、以及用于本地代理测试的BenderProxy。提示需要增删依赖时只改这一个文件不要手动编辑paket.lock。版本解析与锁定工作全部交给 Paket 完成。一键同步依赖./dotnet/update-deps.sh修改完paket.dependencies后按 README 要求回到仓库根目录即存在WORKSPACE文件的地方运行./dotnet/update-deps.sh脚本成功后会同时刷新两个文件dotnet/paket.lockPaket 的精确版本锁定文件提交进版本库dotnet/paket.nuget.bzlBazel 侧的 NuGet 依赖仓库声明供.bzl加载解析。之后把paket.dependencies、paket.lock与paket.nuget.bzl的变更一并提交构建系统即可使用新的依赖版本。update-deps.sh 内部到底做了什么结合 dotnet/update-deps.sh 的源码可以把这条魔法命令拆解为三个环节尽可能复用 Bazel 托管的 dotnet。脚本先用bazel info output_base定位 Bazel 输出目录再从external/中查找rules_dotnetdotnetdotnet_*目录下的dotnet可执行文件若找到则用它执行后续步骤否则回退到系统 PATH 中的dotnet脚本第 6–17 行从而保证与 hermetic 构建环境一致的工具版本。恢复工具并运行 Paket。在dotnet目录内依次执行dotnet tool restore dotnet tool run paket installpaket install依据paket.dependencies解析依赖并更新paket.lock新增包或调整版本时也可用paket update。把锁文件翻译给 Bazel。运行bazel run rules_dotnet//tools/paket2bazel:paket2bazel \ -- --dependencies-file $(pwd)/paket.dependencies --output-folder $(pwd)这一步调用paket2bazel工具基于paket.dependencies与解析结果重新生成paket.nuget.bzl等 Bazel 可加载文件——这正是一次改依赖、构建即生效的关键桥接。脚本末尾还会执行bazel run //scripts:update_docfx同步文档站点配置。在 Bazel 里直接跑 Paketpaket_deps 规则除 shell 脚本外模块还提供了 Bazel 侧的等价入口。从 dotnet/BUILD.bazel 可见paket_deps( name paket-update, mode update, ) paket_deps( name paket-install, mode install, )该规则的实现位于 dotnet/private/paket_deps.bzl它通过rules_dotnet//dotnet:toolchain_type拿到 Bazel 托管的 dotnet 工具链按目标平台Windows 生成.batUnix 生成.sh产出执行脚本脚本会自动定位dotnet/.config/dotnet-tools.json、执行dotnet tool restore与paket {mode}并提示下一步运行paket2bazel。也就是说你可以用 Bazel 自身的依赖管理机制来收敛工具链而不依赖系统全局安装的 dotnet——这再次呼应了 README 强调的 hermetic 构建哲学。从依赖更新到真正消费构建链路闭环完成依赖同步后重新执行bazel build dotnet/...Bazel 会依据更新后的paket.nuget.bzl拉取新的 NuGet 包paket.nuget.org外部仓库由 dotnet/paket.nuget.bzl 声明重新编译受影响的目标。日常的修改依赖 → 重新构建 → 运行测试闭环由此形成。日常开发补充打开 IDE 与运行测试README 提到的先 Bazel 构建、再打开 VS 工程原因在于 IDEVisual Studio / Rider 打开 dotnet/Selenium.slnx需要源码工程里引用到的本地生成产物与 Bazel 下载的依赖已就位。构建完成后即可获得与bazel build结果一致的还原状态。在改动可能影响行为时建议按 dotnet/TESTING.md 用 Bazel 跑测试验证例如bazel test //dotnet/test/webdriver:ElementFindingTests --pin_browserstrue bazel test //dotnet/test/webdriver/... --pin_browserstrue测试套件由 dotnet/test/webdriver/BUILD.bazel 中的dotnet_nunit_test_suite声明它会将dotnet/test/webdriver下所有*.cs编译为单一测试二进制再按浏览器列表firefox、safari、ie、edge 等与测试类生成目标测试文件引用的页面资源、浏览器驱动则由同文件中的test-data文件组提供。注意该文件第 35–37 行的注释明确说明列表中的第一个浏览器firefox作为默认浏览器。小结三条必须记住的命令整个 dotnet/README.md 的构建与依赖管理实践最终可以收敛为以下工作流场景命令 / 操作首次开发前构建全部产物bazel build dotnet/...仓库根目录执行首次较慢一次性安装本地 Paket 工具dotnet new tool-manifest dotnet tool install paket dotnet tool restoredotnet目录内增删/升级依赖编辑 dotnet/paket.dependencies回到仓库根执行./dotnet/update-deps.sh提交paket.lock与paket.nuget.bzl理解这套Bazel 管工具链与构建、Paket 管 NuGet 依赖、paket2bazel 管两界桥接的架构后你就能在 Selenium 这个大型 monorepo 中自如地为 .NET Bindings 增删依赖、执行构建并验证测试而不会因为环境差异陷入我机器上能编译、CI 上失败的困境。【免费下载链接】seleniumA browser automation framework and ecosystem.项目地址: https://gitcode.com/GitHub_Trending/se/selenium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考