[dotnet] Direct dependency on Microsoft.Bcl.AsyncInterfaces

[nvborisenko]

To help MSBuild resolve cross-TFM graph.

💥 What does this PR do?

• Adds Microsoft.Bcl.AsyncInterfaces dependency for Selenium.WebDriver package

🔧 Implementation Notes

Now Tests project can eliminate the dependency.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s):
  • What was generated:
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• Cleanup (formatting, renaming)
• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

Review Summary by Qodo

Add Microsoft.Bcl.AsyncInterfaces dependency and expand multi-targeting

✨ Enhancement

Walkthroughs

Description

• Add direct dependency on Microsoft.Bcl.AsyncInterfaces to WebDriver package
• Expand Selenium.Support multi-targeting to net462 and net8.0
• Remove redundant AsyncInterfaces dependency from test project
• Update nuspec files to reflect new target framework support

Diagram

flowchart LR
  A["WebDriver Package"] -->|"adds direct dependency"| B["Microsoft.Bcl.AsyncInterfaces"]
  C["Selenium.Support"] -->|"expands to"| D["net462, netstandard2.0, net8.0"]
  E["Test Project"] -->|"removes redundant"| F["AsyncInterfaces dependency"]

Loading

File Changes

1. dotnet/src/support/BUILD.bazel ⚙️ Configuration changes +64/-2

Split support library into multi-framework targets

• Split single support target into three framework-specific targets: support-net462,
 support-netstandard2.0, support-net8.0
• Add Microsoft.Bcl.AsyncInterfaces and System.Threading.Tasks.Extensions dependencies to net462 and
 netstandard2.0 targets
• Create backwards-compatible alias pointing support to support-netstandard2.0
• Update nuget_pack to include all three framework variants

dotnet/src/support/BUILD.bazel

---

2. dotnet/src/support/Selenium.Support.csproj ⚙️ Configuration changes +1/-1

Enable multi-framework targeting for Support library

• Change TargetFramework from single netstandard2.0 to multi-targeting with net462, netstandard2.0,
 and net8.0

dotnet/src/support/Selenium.Support.csproj

---

3. dotnet/src/support/Selenium.Support.nuspec ⚙️ Configuration changes +14/-0

Add nuspec entries for new target frameworks

• Add dependency groups for net462 and net8.0 target frameworks
• Include Selenium.WebDriver dependency for all three frameworks
• Add file entries for net462 and net8.0 assemblies, PDB, and XML documentation

dotnet/src/support/Selenium.Support.nuspec

---

View more (4)

4. dotnet/src/webdriver/Selenium.WebDriver.csproj Dependencies +1/-0

Add AsyncInterfaces dependency to WebDriver

• Add Microsoft.Bcl.AsyncInterfaces version 8.0.0 as PackageReference for net462 and netstandard2.0
 target frameworks

dotnet/src/webdriver/Selenium.WebDriver.csproj

---

5. dotnet/src/webdriver/Selenium.WebDriver.nuspec Dependencies +2/-0

Add AsyncInterfaces to WebDriver nuspec

• Add Microsoft.Bcl.AsyncInterfaces version 8.0.0 dependency to net462 and netstandard2.0 dependency
 groups

dotnet/src/webdriver/Selenium.WebDriver.nuspec

---

6. dotnet/test/support/BUILD.bazel Dependencies +1/-2

Remove redundant AsyncInterfaces test dependency

• Dependency now inherited from support-net8.0 library

dotnet/test/support/BUILD.bazel

---

7. dotnet/test/support/Selenium.Support.Tests.csproj Dependencies +0/-1

Remove redundant AsyncInterfaces from tests

• Remove Microsoft.Bcl.AsyncInterfaces PackageReference from test project

dotnet/test/support/Selenium.Support.Tests.csproj

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Repeated Bazel gen runs ✓ Resolved 🐞 Bug ➹ Performance

Description

Multi-targeting Selenium.Support causes Selenium.WebDriver to be built once per TFM via
ProjectReference, and WebDriver’s GenerateBazelArtifacts runs an unconditional bazel build ...
before every CoreCompile, multiplying the Bazel invocation count (and build time) for Support
builds/packs.

Code

dotnet/src/support/Selenium.Support.csproj[4]

+    <TargetFrameworks>net462;netstandard2.0;net8.0;</TargetFrameworks>

Evidence

Support is now cross-targeting and has a ProjectReference to WebDriver; WebDriver defines a
GenerateBazelArtifacts target that always runs bazel build ... before compilation. With
cross-targeting, that implies repeated Bazel invocations during a single Support build/pack (once
per inner TFM build).

dotnet/src/support/Selenium.Support.csproj[3-41]
dotnet/src/webdriver/Selenium.WebDriver.csproj[62-69]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`dotnet build/pack` of `Selenium.Support.csproj` is now cross-targeting (net462/netstandard2.0/net8.0). Because it has a `ProjectReference` to `Selenium.WebDriver.csproj`, WebDriver is built per target framework, and WebDriver’s `GenerateBazelArtifacts` target executes `bazel build ...` before every `CoreCompile`.

This leads to redundant Bazel builds (previously Support was single-TFM), significantly increasing build time and increasing exposure to intermittent Bazel/env failures during normal MSBuild workflows.

### Issue Context
- Support is now multi-targeted and project-references WebDriver.
- WebDriver runs Bazel generation unconditionally in a `BeforeTargets="CoreCompile"` target.

### Fix Focus Areas
- Gate Bazel generation so it runs **once per multi-target build** (outer build) while still running for **single-TFM builds**.
- A typical approach is to:
 - Add a target that runs when `$(IsCrossTargetingBuild) == 'true'` (outer build) before inner builds dispatch, generating artifacts once.
 - Keep a separate path for single-target builds (`$(IsCrossTargetingBuild) != 'true'`) that runs before `CoreCompile`.
- Ensure generated files exist before compilation in all cases.

Fix focus areas (files/lines):
- dotnet/src/support/Selenium.Support.csproj[3-41]
- dotnet/src/webdriver/Selenium.WebDriver.csproj[62-69]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Redundant test package reference 🐞 Bug ⚙ Maintainability

Description

With Selenium.WebDriver now directly referencing Microsoft.Bcl.AsyncInterfaces for
netstandard2.0/net462, Selenium.Support.Tests.csproj still pins the same package explicitly, which
can cause test restores to drift from product dependency resolution over time. This is unnecessary
because Selenium.Support (netstandard2.0) ProjectReferences Selenium.WebDriver, so the dependency
will flow transitively via the referenced project.

Code

dotnet/src/webdriver/Selenium.WebDriver.csproj[57]

+    <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="8.0.0" />

Evidence

Selenium.WebDriver now directly adds the package for net462/netstandard2.0; Selenium.Support targets
netstandard2.0 and ProjectReferences Selenium.WebDriver, so the dependency should flow transitively
to tests via that project reference, making the explicit test PackageReference redundant.

dotnet/src/webdriver/Selenium.WebDriver.csproj[56-60]
dotnet/src/support/Selenium.Support.csproj[3-6]
dotnet/src/support/Selenium.Support.csproj[39-41]
dotnet/test/support/Selenium.Support.Tests.csproj[14-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Selenium.Support.Tests.csproj` still contains an explicit `PackageReference` to `Microsoft.Bcl.AsyncInterfaces`, but after this PR that dependency should already arrive transitively through `Selenium.Support` -> `Selenium.WebDriver` for the netstandard2.0 path.

## Issue Context
- `Selenium.Support` targets `netstandard2.0` and references `Selenium.WebDriver.csproj`.
- `Selenium.WebDriver.csproj` now includes `Microsoft.Bcl.AsyncInterfaces` for `netstandard2.0` / `net462`.
- `Selenium.Support.Tests` still pins `Microsoft.Bcl.AsyncInterfaces` directly.

## Fix Focus Areas
- dotnet/test/support/Selenium.Support.Tests.csproj[14-19]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[selenium-ci]

Thank you, @nvborisenko for this code suggestion.

The support packages contain example code that many users find helpful, but they do not necessarily represent
the best practices for using Selenium, and the Selenium team is not currently merging changes to them.

After reviewing the change, unless it is a critical fix or a feature that is needed for Selenium
to work, we will likely close the PR.

We actively encourage people to add the wrapper and helper code that makes sense for them to their own frameworks.
If you have any questions, please contact us

[qodo-code-review]

Persistent review updated to latest commit 755d507