Selenium: For .net core nuget libs do not copy to bin folder

[NikitaEgorov]

Error in FileUtilities in Selenium .net

For .net core nuget libs do not copy to bin folder.
And WebDriver could not found chromedriver.exe

  /// <summary>
        /// Gets the directory of the currently executing assembly.
        /// </summary>
        /// <returns>The directory of the currently executing assembly.</returns>
        public static string GetCurrentDirectory()
        {
>>>>            Assembly executingAssembly = typeof(FileUtilities).Assembly;
>>>>            string location =  Path.GetDirectoryName(executingAssembly.Location);
            if (string.IsNullOrEmpty(location))
            {
                // If there is no location information from the executing
                // assembly, we will bail by using the current directory.
                // Note this is inaccurate, because the working directory
                // may not actually be the directory of the current assembly,
                // especially if the WebDriver assembly was embedded as a
                // resource.
                location = Directory.GetCurrentDirectory();
            }

            string currentDirectory = location;

            // If we're shadow copying, get the directory from the codebase instead
            if (AppDomain.CurrentDomain.ShadowCopyFiles)
            {
                Uri uri = new Uri(executingAssembly.CodeBase);
                currentDirectory = Path.GetDirectoryName(uri.LocalPath);
            }

            return currentDirectory;
        }

Workaround: <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

[barancev]

chromedriver.exe is not a part of Selenium libs deployed to NuGet, it should be downloaded independently.

[NikitaEgorov]

Line string location = Path.GetDirectoryName(executingAssembly.Location);
Return incorrect path!!!

https://github.com/dotnet/cli/issues/6261

@barancev

[barancev]

Define "incorrect". Does it return location of the assembly as stated in the comments?

[NikitaEgorov]

It return %UserProfile%\.nuget\package\selenium.webdriver\...
But should return current application path

[barancev]

Why do think it should? It's the path to the assembly. If you want it to be copied to the bin directory -- configure your project. Libraries should not make a decision whether they have to be copied or not. You should.

[NikitaEgorov]

Standard path to find all dependencies - current working directory.

[barancev]

1) Please provide a link to this standard for a proof :)
2) Current working dir != project dir, for example if you run tests from Visual Studio using NUnit3 the currect working directory will be somewhere inside the Visual Studio installation directory.
3) geckodriver.exe (an external executable file) is not a dependency.

[NikitaEgorov]

1. https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies :)
2. Yes. it's true. But you invent new dir :)
3. "is not a dependency" - service stop work without this dependency "The {0} file does not exist in the current directory or in a directory on the PATH environment variable. The driver can be downloaded at {1}."

I have a new idea

Add directory of assembly to exception message
"The {0} file does not exist in the ***current directory*** or in a directory on the PATH environment variable. The driver can be downloaded at {1}."

[barancev]

1. It's related to application deployment. You should decide what deps should be deployed within your app and what should not. That's what the project configuration is intended for.
2. Selenium does not invent new directory. It checks the assembly location, the current working dir and PATH.
3. You can't use Selenium without a browser too, but it does not mean Selenium should install a browser as a dependency or copy it somewhere. We expect that browser vendors will install these executable files as a part of the browser soon. Edge (dev preview) and Safari do this already. These executables are tied more to browser than Selenium client library.
4. It's not recommended to put executable files to the assembly location (because this directory is managed by a tool, not a user), so we'll not change the message. On the other hand, some frameworks that extend Selenium expect executables to be near the assembly, that's why this undocumented feature exists. It's not expected to be utilized by end users.

[NikitaEgorov]

Ok.

But

Selenium does not invent new directory. It checks the assembly location, the current working dir and PATH.

current working dir - used only if assembly is embedded!
Please, use CWD for all cases

[barancev]

Ah, yes, there is a collision.

https://github.com/SeleniumHQ/selenium/blob/master/dotnet/src/webdriver/Internal/FileUtilities.cs#L113-L115
reads

        /// This method looks first in the directory of the currently executing
        /// assembly. If the specified file is not there, the method then looks in
        /// each directory on the PATH environment variable, in order.

whereas
https://github.com/SeleniumHQ/selenium/blob/master/dotnet/src/webdriver/DriverService.cs#L270
and
https://github.com/SeleniumHQ/selenium/blob/master/dotnet/src/webdriver/DriverService.cs#L277
mention "the current directory" that implicitly reads as "the current working directory".

Thank you for perseverance, reopening the issue.

[taspeotis]

I have the same issue, the workaround is simply to specify . for driverPath e.g. ChromeDriverService.CreateDefaultService(".").

The GetCurrentDirectory function is poorly named since it does not get the current directory however I recognise that the current working directory != where the files are always. To me a better solution would be to look in these directories for chromedriver.exe rather than assuming one directory must have the file based on shadow copy settings etc. Approximately:

string GetDefaultChromeDriverPath()
{
  if (ChromeDriverExistsInCwd())
    return cwd;

  if (ChromeDriverExistsBesideAssemblyLocation())
    return assemblyDirectory;

  if (ChromeDriverExistsInShadowCopyLocation())
    return ...;

  if (ChromeDriverExistsInPath())
    return ...;

  throw new NotFoundException();
}

Personally I placed the PATH check right at the end because I assume it's a feature to check the file system locations "closer" to the application than in the PATH i.e. if I have an old version of chromedriver.exe in my PATH but one copied to my bin folder ... please use the bin folder one.

Anyway, thank you for Selenium and maintaining the code and GitHub issues.