Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For .net core nuget libs do not copy to bin folder #6130

Closed
NikitaEgorov opened this issue Jul 9, 2018 · 15 comments
Closed

For .net core nuget libs do not copy to bin folder #6130

NikitaEgorov opened this issue Jul 9, 2018 · 15 comments
Labels
C-dotnet I-stale Applied to issues that become stale, and eventually closed.

Comments

@NikitaEgorov
Copy link

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
Copy link
Member

barancev commented Jul 9, 2018

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

@barancev barancev closed this as completed Jul 9, 2018
@NikitaEgorov
Copy link
Author

NikitaEgorov commented Jul 9, 2018

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

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

@barancev

@barancev
Copy link
Member

barancev commented Jul 9, 2018

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

@NikitaEgorov
Copy link
Author

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

@barancev
Copy link
Member

barancev commented Jul 9, 2018

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
Copy link
Author

Standard path to find all dependencies - current working directory.

@barancev
Copy link
Member

barancev commented Jul 9, 2018

  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
Copy link
Author

NikitaEgorov commented Jul 9, 2018

  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
Copy link
Member

barancev commented Jul 9, 2018

  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
Copy link
Author

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
Copy link
Member

barancev commented Jul 9, 2018

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.

@barancev barancev reopened this Jul 9, 2018
@taspeotis
Copy link

taspeotis commented May 13, 2019

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.

@github-actions
Copy link

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the I-stale Applied to issues that become stale, and eventually closed. label Oct 21, 2021
@github-actions
Copy link

github-actions bot commented Nov 4, 2021

This issue was closed because it has been stalled for 14 days with no activity.

@github-actions github-actions bot closed this as completed Nov 4, 2021
@github-actions
Copy link

github-actions bot commented Dec 5, 2021

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C-dotnet I-stale Applied to issues that become stale, and eventually closed.
Projects
None yet
Development

No branches or pull requests

3 participants