[dotnet] Do not warn when passing in null driver paths to driver service

[RenderMichael]

User description

Description

This avoids warning users when passing in null for a driver service's driver directory path or filename.

Motivation and Context

Fixes #15320

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

PR Type

Bug fix

---

Description

• Updated driver service methods to accept nullable parameters.

• Fixed potential null reference warnings in driver service creation.

• Ensured compatibility with nullable reference types (NRT) in .NET.

---

Changes walkthrough 📝

Relevant files

Bug fix

ChromeDriverService.cs Allow nullable parameters in ChromeDriverService methods  dotnet/src/webdriver/Chrome/ChromeDriverService.cs Updated CreateDefaultService methods to accept nullable parameters. Adjusted method signatures to use string? for driverPath and driverExecutableFileName. +2/-2      EdgeDriverService.cs Allow nullable parameters in EdgeDriverService methods      dotnet/src/webdriver/Edge/EdgeDriverService.cs Updated CreateDefaultService methods to accept nullable parameters. Adjusted method signatures to use string? for driverPath and driverExecutableFileName. +2/-2      FirefoxDriverService.cs Allow nullable parameters in FirefoxDriverService methods dotnet/src/webdriver/Firefox/FirefoxDriverService.cs Updated CreateDefaultService methods to accept nullable parameters. Adjusted method signatures to use string? for driverPath and driverExecutableFileName. +2/-2      InternetExplorerDriverService.cs Allow nullable parameters in InternetExplorerDriverService methods dotnet/src/webdriver/IE/InternetExplorerDriverService.cs Updated CreateDefaultService methods to accept nullable parameters. Adjusted method signatures to use string? for driverPath and driverExecutableFileName. +2/-2      SafariDriverService.cs Allow nullable parameters in SafariDriverService methods  dotnet/src/webdriver/Safari/SafariDriverService.cs Updated CreateDefaultService methods to accept nullable parameters. Adjusted method signatures to use string? for driverPath and driverExecutableFileName. +2/-2

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 15320 - Fully compliant Compliant requirements: Fix build errors when passing nullable parameters to CreateDefaultService APIs Allow passing null values for driver path and executable name parameters Update NRT annotations for Edge and Firefox drivers (and other affected drivers)

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Null Check The File.Exists() method is called directly on potentially null driverPath parameter. This could throw a NullReferenceException if driverPath is null. if (File.Exists(driverPath))

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Prevent null reference exception Add null check before calling File.Exists to prevent NullReferenceException when driverPath is null dotnet/src/webdriver/Chrome/ChromeDriverService.cs [69-70] -if (File.Exists(driverPath)) +if (driverPath != null && File.Exists(driverPath)) { Apply this suggestion Suggestion importance[1-10]: 9 __ Why: Critical suggestion that prevents a potential NullReferenceException when driverPath is null, which is now possible since the parameter was made nullable. This check is essential for runtime stability.	High
Update

[nvborisenko]

Interesting behavior:

if (File.Exists(driverPath))
{
    fileName = Path.GetFileName(driverPath);
    driverPath = Path.GetDirectoryName(driverPath)!;
}
else
{
    fileName = ChromiumDriverServiceFileName(DefaultChromeDriverServiceExecutableName);
}

I am user, I call method ChromeDriverService.CreateDefault("this is my driver path!!!!"), and the library silently ignore it. In my opinion this is bad behavior, the library should take into account everything user specified explicitly, otherwise fallback to defaults.

@RenderMichael do you think the same?

[RenderMichael]

@nvborisenko I completely agree. It would be a breaking change (I think a good one?) so maybe it should come with v5? Or can we do it for 4.30?

[nvborisenko]

Good one breaking change. Existing users will not be broken (because they are already in happy branch). So it is a breaking change for users who "thinks they are in happy branch". I propose to fix in in minor selenium version.

Thanks Mike.

[RenderMichael]

That’s also a good point, in a way every bug fix is a “breaking change”. I will update this PR shortly to throw a good exception.

[RenderMichael]

Digging into this a little bit, I misinterpreted how this method family functioned, and there is no bug. It looks like the driverPath parameter can be two things:

• The path directly to the chromedriver.exe/geckodriver.exe/etc. file (with a potentially different file name of course)
• The directory containing the driver (and it assumes the driver file name is the regular one, eg. chromedriver.exe).

I refactored the methods to clarify this functionality better.

[nvborisenko]

Thanks @RenderMichael, looks good.