My instance of IE Selenium is not loading for users who are not administrators

Question

I wrote an application in C # to automate login to a web page.

It works great whenever an administrator runs an executable file. Whenever a non-admin starts a project, it is as if IEDriver.exe does not start. There are no restrictions on starting IEDriver.exe from Group Policy.

private IWebDriver _driver; public void SetUp() { InternetExplorerOptions options = new InternetExplorerOptions(); options.EnsureCleanSession = true; options.IntroduceInstabilityByIgnoringProtectedModeSettings = true; options.RequireWindowFocus = true; options.EnablePersistentHover = false; var service = InternetExplorerDriverService.CreateDefaultService(); service.LibraryExtractionPath = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location); //service.HideCommandPromptWindow = true; _driver = new InternetExplorerDriver(service, options); } 

when I uncomment LibraryExtractionPath, the IEDriver does not start.

When I debug the code.

  Path.GetDirectoryName(Assembly.GetEntryAssembly().Location); 

indicates the correct location which

D: \ PathToFolder \ Project1 \ Bin \ Debug \

I think the problem is that clients (like non-admin) cannot start IEDriver.exe

UPDATE: Internet Explorer protected mode is not disabled, which may prevent the IE driver from starting as a non-administrator user . Can I disable it using C # code and IE service settings?

Answer 1

From the view of the path that you have provided

D: \ PathToFolder \ Project1 \ Bin \ Debug \

You are trying to start the driver from which it was compiled by Visual Studio. There are several reasons why this may not work.

When you configure and compile the code in visual studio, it would create an ect debug folder and use the permissions of the current user. This means that this user and administrators can access him, but not to anyone else. Or, if it was done as an administrator, it can only be accessed by administrators.

Quiet often, Visual Studio and other IDEs will also have a different working directory and compile exe into different directories depending on which build options you have selected. For example, release and debugging. This means that the dll ect used by exe is not in the same directive as exe. When you start visual studio, this is not a problem, as it sets the correct working directory and sorts it all for you. In your case, it's probably not that simple if it is part of the problem. This may mean that any dll-ect required can be installed on the way for the administrator, but not for ordinary users.

That this breaks down is probably a problem with paths or permissions. I would suggest using something like Walker Dependency to find out what is from exe: http://www.dependencywalker.com/ and ensure that all users can access them.

If you do this as a user that the program does not work for dependencies, the walker will show you which dependencies were not found.