[🚀 Feature]: [dotnet] Web driver (options) builder

[nvborisenko]

Description

Currently:

var options = new ChromeOptions();
options.AddArgument("--a");
options.UseWebSocketUrl = true;
var chrome = new ChromeDriver(options);

Have you considered any alternatives or workarounds?

var chrome = new ChromeDriver(hd =>
{
    hd.AddArguments("--a").UseWebSockeUrl();
});

Why:
Currently there are so many constructor overloads. And even all of them don't cover everything what it can opt-in. To specify commandTimeout I should use some constructor where commandTimeout is last argument. If we will support one more argument, then we should duplicate all constructors.

Conceptually, any WebDriver is:

1. DriverService (chromedriver.exe)
2. Browser options (Capabilities?)
3. HTTP client (transport)

WebDriverBuilder will be single entry point, allowing:

• Fluently describe what driver to start
• Configure driver service (even to be reusable if user wants)
• Configure HTTP low-level client

Pseudo example:

var chrome = new ChromeDriver(hd =>
{
    hd.WithVersion("145.1").
        .WithService(s => s.UseFeatureA().UseFeatureB()) // or .WithService(_myExistingService)
        .WithHttp(h => { h.DefaultHeaders.Add("x-name", "john"); h.UseProxy = false } );
});

[selenium-ci]

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[DeLaphante]

@nvborisenko Method chaining looks elegant but in this case it blurs responsibility boundaries. You end up chaining unrelated concerns...browser options, driver service and transport which creates the illusion of cohesion where none exists. It also hides lifecycle and ordering constraints...allowing invalid but compilable states and pushing errors to runtime. Constructor overloads are ugly but fluent builders often just replace them with mutable "god builders". The real fix isn't chaining for aesthetics, it's explicit composition of service, options and transport so responsibilities stay clear and predictable.

The real issue isn't syntax...it's missing composition

The core problem you're identifying is valid:
WebDriver = Service + Options + Transport

But the solution is explicit composition and not chaining:

var service = ChromeDriverService.CreateDefaultService();
service.UseFeatureA();
var options = new ChromeOptions();
options.AddArgument("--a");
var http = new WebDriverHttpClient { UseProxy = false };
var driver = new ChromeDriver(service, options, http, timeout);

This:

1. Preserves boundaries
2. Avoids overload explosion
3. Keeps configuration explicit
4. Allows reuse safely

[nvborisenko]

I am currently evaluating several potential features (e.g., Selenium issue #17121) and analyzing their implementation paths. For instance, we may be able to reuse local service.
However, adding these features via standard constructors would lead to constructor overload explosion, creating a maintenance burden and a messy public API. To resolve this, I'm proposing a Builder pattern. This would allow us to keep the API clean while providing a flexible way to configure new options.
Before we proceed, we should audit exactly what needs to be added as a public.