[dotnet] support SE_*DRIVER environment variables to set driver locations

[titusfortner]

🔗 Related Issues

Part of #14045

💥 What does this PR do?

• Adds .NET support for setting driver locations via environment variables, bringing it in line with Ruby, Python, and Java.
• When set, the matching variable is used to locate the driver and Selenium Manager is skipped: SE_CHROMEDRIVER, SE_EDGEDRIVER, SE_GECKODRIVER, SE_IEDRIVER, SE_SAFARIDRIVER.
• An explicitly configured driver path still takes precedence over the environment variable.

🔧 Implementation Notes

• Resolution order matches Java/Ruby: configured path → environment variable → Selenium Manager.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: implementation and tests
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

PR Summary by Qodo

.NET: Support SE_*DRIVER env vars to locate browser drivers (skip Selenium Manager)

✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

AI Description

• Add per-browser SE_*DRIVER environment variables to resolve driver executable paths.
• Prefer configured driver path, then environment variable, then Selenium Manager (DriverFinder).
• Add unit tests verifying DriverService reads the expected environment variables.

Diagram

graph TD
  A["Browser Driver ctor"] --> B["DriverService"] --> C{"Driver path resolved?"}
  C -->|"Configured"| D["DriverServicePath/Exe"] --> G["Driver process"]
  C -->|"SE_*DRIVER"| E["Env var driver path"] --> G
  C -->|"None"| F["DriverFinder (Selenium Manager)"] --> D

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Centralize env-var resolution in DriverService (single helper)

• ➕ Avoids duplicating the same env-var branching across Chromium/Firefox/IE/Safari driver startup methods
• ➕ Makes it harder for future drivers to forget the env-var precedence rule
• ➖ May require broader refactoring of driver startup to keep browser binary resolution (BinaryLocation/BrowserVersion) correct for Chromium/Firefox only

2. Introduce a shared internal utility for resolving service path/exe

• ➕ Keeps current call sites but reduces repeated Path.GetDirectoryName/GetFileName logic
• ➕ Limits refactor scope to small helper methods
• ➖ Still leaves precedence logic spread across multiple drivers unless the helper owns the policy

Recommendation: The PR’s approach (base DriverService exposes env-var value; per-driver overrides specify the variable; startup paths short-circuit Selenium Manager when env var is set) is aligned with other language bindings and keeps the policy explicit. If follow-up cleanup is desired, consider extracting the repeated env-var-to-(path, exe) assignment into a small internal helper to reduce duplication without changing behavior.

Files changed (11) +147 / -22

Enhancement (10) +90 / -22

ChromeDriverService.csExpose SE_CHROMEDRIVER as Chrome service env-var override +3/-0

Expose SE_CHROMEDRIVER as Chrome service env-var override

• Overrides the base DriverService environment variable hook so ChromeDriverService can read SE_CHROMEDRIVER for an explicit driver executable path.

dotnet/src/webdriver/Chrome/ChromeDriverService.cs

ChromiumDriver.csUse env-provided driver path before DriverFinder (Selenium Manager) +15/-7

Use env-provided driver path before DriverFinder (Selenium Manager)

• When DriverServicePath is not explicitly configured, checks DriverPathFromEnvironment first and uses it to set service directory/executable. Falls back to DriverFinder only when the env var is absent, preserving existing browser binary resolution logic.

dotnet/src/webdriver/Chromium/ChromiumDriver.cs

DriverService.csAdd env-var based driver path resolution and startup support +21/-0

Add env-var based driver path resolution and startup support

• Introduces a virtual DriverServiceEnvironmentVariable and a DriverPathFromEnvironment accessor to read non-empty env var values. Updates StartAsync to directly launch the driver using the env-provided executable path when no service path is configured, skipping Selenium Manager.

dotnet/src/webdriver/DriverService.cs

EdgeDriverService.csExpose SE_EDGEDRIVER as Edge service env-var override +3/-0

Expose SE_EDGEDRIVER as Edge service env-var override

• Overrides the base DriverService environment variable hook so EdgeDriverService can read SE_EDGEDRIVER for an explicit driver executable path.

dotnet/src/webdriver/Edge/EdgeDriverService.cs

FirefoxDriver.csUse env-provided driver path before DriverFinder (Selenium Manager) +15/-7

Use env-provided driver path before DriverFinder (Selenium Manager)

• When DriverServicePath is not explicitly configured, checks DriverPathFromEnvironment first and uses it to set service directory/executable. Falls back to DriverFinder only when the env var is absent, preserving existing browser binary resolution behavior.

dotnet/src/webdriver/Firefox/FirefoxDriver.cs

FirefoxDriverService.csExpose SE_GECKODRIVER as Firefox service env-var override +3/-0

Expose SE_GECKODRIVER as Firefox service env-var override

• Overrides the base DriverService environment variable hook so FirefoxDriverService can read SE_GECKODRIVER for an explicit driver executable path.

dotnet/src/webdriver/Firefox/FirefoxDriverService.cs

InternetExplorerDriver.csUse env-provided driver path before DriverFinder (Selenium Manager) +12/-4

Use env-provided driver path before DriverFinder (Selenium Manager)

• When DriverServicePath is not explicitly configured, checks DriverPathFromEnvironment first and uses it to set service directory/executable. Falls back to DriverFinder only when the env var is absent.

dotnet/src/webdriver/IE/InternetExplorerDriver.cs

InternetExplorerDriverService.csExpose SE_IEDRIVER as IE service env-var override +3/-0

Expose SE_IEDRIVER as IE service env-var override

• Overrides the base DriverService environment variable hook so InternetExplorerDriverService can read SE_IEDRIVER for an explicit driver executable path.

dotnet/src/webdriver/IE/InternetExplorerDriverService.cs

SafariDriver.csUse env-provided driver path before DriverFinder (Selenium Manager) +12/-4

Use env-provided driver path before DriverFinder (Selenium Manager)

• When DriverServicePath is not explicitly configured, checks DriverPathFromEnvironment first and uses it to set service directory/executable. Falls back to DriverFinder only when the env var is absent.

dotnet/src/webdriver/Safari/SafariDriver.cs

SafariDriverService.csExpose SE_SAFARIDRIVER as Safari service env-var override +3/-0

Expose SE_SAFARIDRIVER as Safari service env-var override

• Overrides the base DriverService environment variable hook so SafariDriverService can read SE_SAFARIDRIVER for an explicit driver executable path.

dotnet/src/webdriver/Safari/SafariDriverService.cs

Tests (1) +57 / -0

DriverServiceTests.csAdd tests for SE_*DRIVER environment variable reading +57/-0

Add tests for SE_*DRIVER environment variable reading

• Adds a parameterized test validating that each DriverService implementation reads the correct SE_*DRIVER variable into DriverPathFromEnvironment, restoring the original env var after the test.

dotnet/test/webdriver/DriverServiceTests.cs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Racy env-var test ✓ Resolved 🐞 Bug ☼ Reliability

Description

DriverServiceTests mutates process-wide SE_*DRIVER environment variables, so parallel test execution
can observe the temporary fake driver path and fail when creating real drivers. This introduces
non-deterministic test failures depending on NUnit parallel scheduling.

Code

dotnet/test/webdriver/DriverServiceTests.cs[R48-51]

+            Environment.SetEnvironmentVariable(environmentVariable, expectedPath);
+            using DriverService service = createService();
+            Assert.That(service.DriverPathFromEnvironment, Is.EqualTo(expectedPath));
+        }

Evidence

The new test sets and later restores global environment variables; other tests may run concurrently
(parallelizable fixtures exist) and the production code reads these variables to locate driver
executables.

dotnet/test/webdriver/DriverServiceTests.cs[41-55]
dotnet/test/webdriver/BiDi/BiDiFixture.cs[24-49]
dotnet/src/webdriver/DriverService.cs[150-166]

Agent prompt

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

### Issue description
`DriverServiceTests` sets process-wide `SE_*DRIVER` environment variables during the test. If any other tests run in parallel and create drivers/services, they may read the temporary value and fail.

### Issue Context
The test suite includes parallelizable fixtures, so this can become a flaky CI failure.

### Fix
Mark this fixture as non-parallelizable (or otherwise serialize env-var mutation), and keep the existing try/finally restore.

### Fix Focus Areas
- dotnet/test/webdriver/DriverServiceTests.cs[29-56]
- dotnet/test/webdriver/BiDi/BiDiFixture.cs[24-35]

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

---

2. Brittle exception message assert ✗ Dismissed 🐞 Bug ☼ Reliability ⭐ New

Description

DriverServiceTests requires Win32Exception.Message to contain the fake driver path, but that message
text/format is not a stable contract across OS/runtime/localization. This can make the test fail
even when the env-var driver resolution is working correctly.

Code

dotnet/test/webdriver/DriverServiceTests.cs[R52-54]

+            Assert.That(
+                async () => await createService().StartAsync(),
+                Throws.InstanceOf<Win32Exception>().With.Message.Contains(expectedPath));

Evidence

The test currently validates env-var selection by checking the thrown exception message contains the
path, but DriverService.StartAsync ultimately calls Process.Start() without wrapping the exception,
so the message content is determined externally and is not guaranteed to include the filename in a
consistent format. A stable test seam exists via the DriverProcessStarting event, which fires with
the selected StartInfo.FileName before process start.

dotnet/test/webdriver/DriverServiceTests.cs[52-54]
dotnet/src/webdriver/DriverService.cs[227-246]
dotnet/src/webdriver/DriverService.cs[267-271]
dotnet/src/webdriver/DriverService.cs[55-63]

Agent prompt

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

### Issue description
`DriverServiceTests.StartsDriverFromEnvironmentVariable` asserts that `Win32Exception.Message` contains `expectedPath`. Exception messages from `Process.Start()` are platform/runtime/localization dependent, so this assertion can be flaky.

### Issue Context
The production code raises `DriverProcessStarting` with the `ProcessStartInfo` immediately before calling `Process.Start()`. This provides a stable way for the test to verify which executable path was selected (configured/env-manager) without relying on exception-message text.

### Fix Focus Areas
- dotnet/test/webdriver/DriverServiceTests.cs[52-54]

### Suggested fix
- Create the service instance first: `var service = createService();`
- Subscribe to `service.DriverProcessStarting` and capture `e.StartInfo.FileName`.
- Call `StartAsync()` and assert it throws `Win32Exception` (type only).
- Assert the captured `FileName` equals `expectedPath`.

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

---

3. No log for env driver ✓ Resolved 📘 Rule violation ◔ Observability

Description

When DriverPathFromEnvironment is used, the driver resolution path changes (skipping Selenium
Manager) but no log indicates which source was chosen. This makes driver startup failures harder to
diagnose and violates the requirement to add logging where users need operational insight.

Code

dotnet/src/webdriver/DriverService.cs[R238-241]

+        else if (this.DriverPathFromEnvironment is string environmentDriverPath)
+        {
+            this.driverServiceProcess.StartInfo.FileName = environmentDriverPath;
+        }

Evidence

PR Compliance ID 6 requires adding logging for user-impacting operational behavior. The updated
StartAsync flow adds an environment-variable-based resolution path (skipping Selenium Manager) but
does not emit any log indicating this resolution was chosen, leaving users without insight into why
a particular driver path was used.

AGENTS.md: Add Logging Where Users Need Operational Insight
dotnet/src/webdriver/DriverService.cs[229-247]

Agent prompt

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

## Issue description
The driver startup path now supports resolving the driver executable via `SE_*DRIVER` environment variables, but there is no logging indicating that an environment variable was used (and which one). This reduces diagnosability when startup fails due to a bad path or unexpected environment configuration.

## Issue Context
`DriverService.StartAsync` selects the executable from either an explicitly configured path, an environment variable, or Selenium Manager. The new environment-variable branch sets `StartInfo.FileName` directly without any log statement.

## Fix Focus Areas
- dotnet/src/webdriver/DriverService.cs[229-247]

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

---

4. Env path not sanitized ✗ Dismissed 🐞 Bug ≡ Correctness

Description

DriverService.DriverPathFromEnvironment treats any non-empty value as a valid path without
trimming/normalizing, so whitespace-only or quoted values are passed through and used as the process
FileName. This can cause avoidable driver startup failures that are difficult to diagnose.

Code

dotnet/src/webdriver/DriverService.cs[R161-164]

+        this.DriverServiceEnvironmentVariable is string name
+        && Environment.GetEnvironmentVariable(name) is string path
+        && path.Length > 0
+            ? path

Evidence

The code path checks only path.Length > 0 and then uses the returned value directly as the process
executable path, so malformed env-var values can be consumed without any normalization.

dotnet/src/webdriver/DriverService.cs[150-166]
dotnet/src/webdriver/DriverService.cs[227-247]

Agent prompt

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

### Issue description
`DriverPathFromEnvironment` considers any `Length > 0` value as set and returns it verbatim. `StartAsync` then uses that string directly as `ProcessStartInfo.FileName`, so malformed values (e.g., whitespace-only, or surrounding quotes) can break driver startup.

### Issue Context
This PR adds support for `SE_*DRIVER` variables, making this parsing path user-facing.

### Fix
- Treat whitespace-only values as unset (`string.IsNullOrWhiteSpace`).
- Trim leading/trailing whitespace.
- Optionally strip a single pair of surrounding quotes (`"..."`) if present.
- (Optional but helpful) if the normalized value ends with a directory separator or produces an empty file name, throw a clear exception explaining the expected format.

### Fix Focus Areas
- dotnet/src/webdriver/DriverService.cs[150-166]
- dotnet/src/webdriver/DriverService.cs[229-247]

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

---

5. Nullable env var type ✗ Dismissed 🐞 Bug ⚙ Maintainability

Description

DriverServiceTests assigns Environment.GetEnvironmentVariable (nullable) into a non-nullable string,
which can produce nullable-analysis warnings and reduce test code clarity. This is low impact but
easy to fix.

Code

dotnet/test/webdriver/DriverServiceTests.cs[R44-45]

+        string original = Environment.GetEnvironmentVariable(environmentVariable);
+        string expectedPath = Path.Combine("path", "to", "driver");

Evidence

The test stores a possibly-null environment variable in a non-nullable local variable.

dotnet/test/webdriver/DriverServiceTests.cs[41-55]

Agent prompt

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

### Issue description
`Environment.GetEnvironmentVariable(...)` returns `string?`, but the test stores it in a non-nullable `string`.

### Issue Context
This can produce nullable warnings (and may fail builds if warnings are elevated).

### Fix
Change `string original` to `string? original`.

### Fix Focus Areas
- dotnet/test/webdriver/DriverServiceTests.cs[42-55]

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

---

Context used

✅ Compliance rules (platform): 15 rules

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit c083da4

Results up to commit 19301ce ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Racy env-var test ✓ Resolved 🐞 Bug ☼ Reliability

Description

DriverServiceTests mutates process-wide SE_*DRIVER environment variables, so parallel test execution
can observe the temporary fake driver path and fail when creating real drivers. This introduces
non-deterministic test failures depending on NUnit parallel scheduling.

Code

dotnet/test/webdriver/DriverServiceTests.cs[R48-51]

+            Environment.SetEnvironmentVariable(environmentVariable, expectedPath);
+            using DriverService service = createService();
+            Assert.That(service.DriverPathFromEnvironment, Is.EqualTo(expectedPath));
+        }

Evidence

The new test sets and later restores global environment variables; other tests may run concurrently
(parallelizable fixtures exist) and the production code reads these variables to locate driver
executables.

dotnet/test/webdriver/DriverServiceTests.cs[41-55]
dotnet/test/webdriver/BiDi/BiDiFixture.cs[24-49]
dotnet/src/webdriver/DriverService.cs[150-166]

Agent prompt

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

### Issue description
`DriverServiceTests` sets process-wide `SE_*DRIVER` environment variables during the test. If any other tests run in parallel and create drivers/services, they may read the temporary value and fail.

### Issue Context
The test suite includes parallelizable fixtures, so this can become a flaky CI failure.

### Fix
Mark this fixture as non-parallelizable (or otherwise serialize env-var mutation), and keep the existing try/finally restore.

### Fix Focus Areas
- dotnet/test/webdriver/DriverServiceTests.cs[29-56]
- dotnet/test/webdriver/BiDi/BiDiFixture.cs[24-35]

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

---

2. Env path not sanitized ✗ Dismissed 🐞 Bug ≡ Correctness

Description

DriverService.DriverPathFromEnvironment treats any non-empty value as a valid path without
trimming/normalizing, so whitespace-only or quoted values are passed through and used as the process
FileName. This can cause avoidable driver startup failures that are difficult to diagnose.

Code

dotnet/src/webdriver/DriverService.cs[R161-164]

+        this.DriverServiceEnvironmentVariable is string name
+        && Environment.GetEnvironmentVariable(name) is string path
+        && path.Length > 0
+            ? path

Evidence

The code path checks only path.Length > 0 and then uses the returned value directly as the process
executable path, so malformed env-var values can be consumed without any normalization.

dotnet/src/webdriver/DriverService.cs[150-166]
dotnet/src/webdriver/DriverService.cs[227-247]

Agent prompt

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

### Issue description
`DriverPathFromEnvironment` considers any `Length > 0` value as set and returns it verbatim. `StartAsync` then uses that string directly as `ProcessStartInfo.FileName`, so malformed values (e.g., whitespace-only, or surrounding quotes) can break driver startup.

### Issue Context
This PR adds support for `SE_*DRIVER` variables, making this parsing path user-facing.

### Fix
- Treat whitespace-only values as unset (`string.IsNullOrWhiteSpace`).
- Trim leading/trailing whitespace.
- Optionally strip a single pair of surrounding quotes (`"..."`) if present.
- (Optional but helpful) if the normalized value ends with a directory separator or produces an empty file name, throw a clear exception explaining the expected format.

### Fix Focus Areas
- dotnet/src/webdriver/DriverService.cs[150-166]
- dotnet/src/webdriver/DriverService.cs[229-247]

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

---

3. No log for env driver ✓ Resolved 📘 Rule violation ◔ Observability

Description

When DriverPathFromEnvironment is used, the driver resolution path changes (skipping Selenium
Manager) but no log indicates which source was chosen. This makes driver startup failures harder to
diagnose and violates the requirement to add logging where users need operational insight.

Code

dotnet/src/webdriver/DriverService.cs[R238-241]

+        else if (this.DriverPathFromEnvironment is string environmentDriverPath)
+        {
+            this.driverServiceProcess.StartInfo.FileName = environmentDriverPath;
+        }

Evidence

PR Compliance ID 6 requires adding logging for user-impacting operational behavior. The updated
StartAsync flow adds an environment-variable-based resolution path (skipping Selenium Manager) but
does not emit any log indicating this resolution was chosen, leaving users without insight into why
a particular driver path was used.

AGENTS.md: Add Logging Where Users Need Operational Insight
dotnet/src/webdriver/DriverService.cs[229-247]

Agent prompt

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

## Issue description
The driver startup path now supports resolving the driver executable via `SE_*DRIVER` environment variables, but there is no logging indicating that an environment variable was used (and which one). This reduces diagnosability when startup fails due to a bad path or unexpected environment configuration.

## Issue Context
`DriverService.StartAsync` selects the executable from either an explicitly configured path, an environment variable, or Selenium Manager. The new environment-variable branch sets `StartInfo.FileName` directly without any log statement.

## Fix Focus Areas
- dotnet/src/webdriver/DriverService.cs[229-247]

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

---

4. Nullable env var type ✗ Dismissed 🐞 Bug ⚙ Maintainability

Description

DriverServiceTests assigns Environment.GetEnvironmentVariable (nullable) into a non-nullable string,
which can produce nullable-analysis warnings and reduce test code clarity. This is low impact but
easy to fix.

Code

dotnet/test/webdriver/DriverServiceTests.cs[R44-45]

+        string original = Environment.GetEnvironmentVariable(environmentVariable);
+        string expectedPath = Path.Combine("path", "to", "driver");

Evidence

The test stores a possibly-null environment variable in a non-nullable local variable.

dotnet/test/webdriver/DriverServiceTests.cs[41-55]

Agent prompt

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

### Issue description
`Environment.GetEnvironmentVariable(...)` returns `string?`, but the test stores it in a non-nullable `string`.

### Issue Context
This can produce nullable warnings (and may fail builds if warnings are elevated).

### Fix
Change `string original` to `string? original`.

### Fix Focus Areas
- dotnet/test/webdriver/DriverServiceTests.cs[42-55]

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

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4c76c9b

[nvborisenko]

Thanks @titusfortner , just cosmetic changes and we need to think how to not expose new public API (most important).

[qodo-code-review]

Code review by qodo was updated up to the latest commit 8e42c8b

[qodo-code-review]

Code review by qodo was updated up to the latest commit c083da4

[titusfortner]

Thanks for fixing, much easier than me trying to figure it out. :)