Selenium - java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.ie.driver system property;

Selenium - java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.ie.driver system property;

IE browser will fail with the above mentioned exception if we upgrade the Selenium webdriver with 2.26.

Reason?
From 2.26 vesrion, IE driver got decoupled from selenium jar file and entire IE driver software is stored in a separate exe file, there are 32 and 64 bit versions.
You need to download the exe file similar to chrome driver and use the following code to run the test.

Sample code Java/TestNG

  WebDriver driver;
@BeforeMethod public void StartDriver() { File file = new File("C:/Seleniumjars/IEDriverServer.exe"); System.setProperty("webdriver.ie.driver", file.getAbsolutePath()); driver = new InternetExplorerDriver(); } @AfterMethod(alwaysRun = true) public void StopDriver() throws Exception { driver.quit(); } @Test(groups = { "GoogleTest" }, enabled = true,timeOut = 90000) public void Test_TC_01_1() throws Exception { driver.get("www.google.com"); }

Technical Reason?
IE driver original implementation was in dll using native C++. As per the client language bindings .dll was extracted during run-time.
For Java extracting from the .jar file.
For .NET extracting it from resource package into WebDriver.dll assembly.
Ruby and Python directly relied on the files, no extraction is required, just reference to the path.
The language bindings would use following method to load the dll and expose the API
JNI for Java
P/Invoke for .NET
ctypes for Python
FFI for Ruby
It works fine for simple scenarios, but due to above differences, IEdriver was showing different behavior between language bindings.
The way .NET bindings loading and managing the .dll, it was able to support multiple instances of IE.
Java bindings was not able to support multiple instances.

In order to unify the experience across all the languages, separate process was created IEDriverServer.exe because now the process management is defined my the operating system (Different version of Windows) and client bindings can interact directly with the process API.

As there is windows limitation where 32 bit process can't be loaded with 64 bit dll, separate 32 and 64 bit process are created.

As the IE driver got decoupled from the selenium release, it is possible to ship the fixes of IE driver without having to wait for complete selenium release.

It is easy to debug a standalone dll then dll loaded by the laungage binding.

Thanks a lot to Jim Evans (IE driver and .NET bindings project lead) for sharing the details and contributing to the open source community.

---