Selenium WebDriver Support For .NET Core 2.0

Starting with release 3.6.0 of the .NET bindings, Selenium now has the initial support for .NET Core 2.0. The .NET bindings in that release contain versions of the assemblies that are build against the .NET Standard 2.0 platform, which means they're intended to be used with .NET Core 2.0 projects. I know this has been a feature many people have wanted for a long time, and I'm glad the project can now deliver it. However, it does come with some associated costs, and with a few known issues.

The first known issue is that calls to localhost in .NET Core are slower than those in the full .NET Framework. This is due to internal differences in the .NET libraries themselves, and are not the fault of the bindings directly. See this issue in the .NET Core repository for more details

Secondly, attempting to save a screenshot to any graphics file format other than Portable Network Graphics (PNG) will throw an exception. .NET Core does not provide the image manipulation classes that the full .NET Framework does, and there are no production-ready third-party libraries that provide that functionality yet and also only rely on managed code. It's fully possible to save a screenshot when using .NET Core, but you can only save it to the PNG file format within the Selenium libraries. This concern is over and above the difficulties with adding dependencies to the language bindings

Speaking of difficulties with adding dependencies to the Selenium project leads me to the next known issue. When using the bindings against .NET Core, there is no PageFactory class available. This is not an oversight, nor is it a bug. I have long said that the .NET PageFactory implementation is not required for effective implementation of the Page Object Pattern, and the .NET PageFactory does not provide any tangible benefits to the user. Even the argument that the code is easier to read is specious with properly constructed page objects. Moreover, the existing .NET PageFactory implementation requires use of classes that are not available in .NET Core. It is a non-trivial matter to add additional dependencies to the .NET bindings, so simply replacing those classes with a third-party library that is compatible with .NET Core is not a "perfectly obvious" option.

Finally, references to the .NET Standard 2.0 library versions provided in this and future releases are only valid when using NuGet package references. Simply copying the assembly and adding an assembly reference to the .NET Core 2.0 project will not work. This is by design of the .NET Core ecosystem, which is now entirely dependent on NuGet to propertly resolve dependencies.

One last note with the 3.6.0 release of the .NET bindings. Previously, the .zip archives that were provided at the official Selenium release site contained only the assemblies (.dlls) for the various frameworks that we supported. Starting with this release, the downloadable .zip archives contain NuGet package (.nupkg) files inside the .zip. To extract the actual .dlls from the packages, you can use any .zip reader to extract files from a .nupkg file. Yes, this means that we're putting a .zip inside a .zip, which is less than efficient, and we may revisit this mechanism of distributing the binary releases in the future.

Announcing Beta Release of Selenium IE Driver

One of the most common question I get asked is, "How can I help contribute to Selenium?" Usually my answer involves pull requests and the like, but today, I can offer a much easier way for people to contribute. A significant part of my attention over the last four years has been thinking about and working on the W3C specification for WebDriver. While the specification codifies many of the things that the open source Selenium project has done for years, there are some significant changes to the wire protocol that the language bindings use to communicate with the drivers themselves. The specification already has an implementation in wide use, in geckodriver, Mozilla's driver implementation for Firefox. In order to move forward, however, the IE driver needs to be updated to follow the specification. Here's where you come in.

I've modified the IE driver to use the W3C dialect of the wire protocol. This modification, while significant internally, shouldn't show any differences in behavior from the existing, shipping IE driver. It currently passes all of the tests in the Selenium project for IE. While these tests are pretty extensive, the permutations available in the DOM and in Selenium WebDriver code used to automate it are nearly infinite. To that end, I'm announcing the availability of a beta version of the IE driver. What am I asking you to do? Simply download the new driver executable, and use it in place of the existing driver you're using in your Internet Explorer automation.

Notes

• The beta driver should be a drop-in replacement for the existing 3.3.0 IEDriverServer.exe release. It should require no changes in your code, save maybe pointing to the new executable.
• Having said that, there are some differences that are expected due to spec compliance. Full-page screenshots, for example, are explicitly disallowed by the specification, so are no longer generated by the driver.
• The beta driver's version number (visible by executing IEDriverServer.exe --version) will be 3.3.99.x. Bug fix releases will increment the "build" (fourth) field of the version number.
• This executable will only be available via the download site; it will not be available via package managers (Maven, NuGet, npm, etc.). If the beta appears in any of the (unofficial) packages that may be used for IEDriverServer.exe in a package manager, a request will be sent to the package owner to remove it, so please don't rely on those.
• There have been some extensive internal rewrites due to the nature of the protocol changes. More on what to look for below.
• Only the 32-bit version of the driver is being provided for the beta.

Areas of Concern

We want to know if there are any differences between the shipping 3.3.0 version of IEDriverServer.exe and the beta version. You should see the same behavior, including bugs; do not expect the beta driver to magically fix issues you may have experienced with IE in the past. Updating to support the specification wire protocol has required extensive rewrites, but these should all be transparent to the language bindings. The biggest changes have happened in the areas of element interactions, so you should pay special attention to things like WebElement.click() or WebElement.sendKeys(). There is one known issue that if you call WebElement.submit(), and the onsubmit event handler throws up a JavaScript alert(), the driver will hang. This issue won't be fixed until after the merge back to master. Also note that the beta has to date only been tested against IE 11, and per the driver's current support policy, only officially supports IE 9, 10, and 11.

Reporting Issues

Issues with the beta can be reported to the Selenium project's issue tracker. However, we have to set some ground rules for the issues that you submit. Here they are:
You'll need to provide the following information with any issue report:

• Language bindings (Java, .NET, Ruby, Python, JavaScript) and version number you're using
• The specific version of the beta you're using
• The WebDriver code that behaves differently
• An HTML page (or link to one) that the WebDriver code can be run against

Lack of any of this information will cause the issue to be closed immediately, without action or investigation! There are simply too many other potential issues with the existing IE driver, and the timeline for getting this merged into the main code line is simply too short to be able to go back and forth with issue reporters trying to set up a reproducible case. Moreover, here are some further guidelines about submitting issues.

• Prefixing your issue title with "IE Driver Beta" will get it processed more quickly than if you don't.
• The beta has only been tested with 3.3.x versions of any language bindings. It should still work with any language bindings of the 3.x vintage, but if you haven't tried your code with at least 3.3.x, you will be asked to do so before further investigation can continue on your issue.
• You should be able to concretely demonstrate a difference in behavior from IEDriverServer.exe 3.3.0 and the beta you're using. If you cannot, you will be asked to do so before investigation can continue.
• If you are using a test framework, and your sample code cannot be extracted to simple, straightforward WebDriver-only code, your issue will be closed. Developer bandwidth is just too narrow to wade through tons of framework code to get to the single few lines of WebDriver code that are exhibiting different behavior.
• If you omit an HTML page that can be tested against, your issue will be closed. Again, this may seem overly restrictive, but without this caveat, it will be nearly impossible to debug the issue with the beta driver.

This is pretty time-sensitive, so if you'd like to give this a try, the Selenium project developers would really appreciate it.

Announcing End of Life of .NET Selenium RC Language Bindings

This post will serve as the official announcement that version 3.1 of the Selenium .NET language bindings will be the last to provide a Selenium RC library. Users still relying on the RC API will be able to continue to do so using WebDriverBackedSelenium, or by converting your code to use WebDriver proper. Selenium RC has been deprecated for over six years, and the .NET Selenium RC language bindings have not been updated with a code change other than a version bump in nearly that long. This change isn't likely to affect many users at this point, and the 3.1 versions of the language bindings will continue to be available more-or-less indefinitely, but there will be no further changes to the .NET RC library or releases of it.

Let me restate again so that it's blatantly obvious. This does not affect the .NET language bindings for WebDriver, and WebDriverBackedSelenium will remain a viable path forward for some time. It only affects Selenium RC in the .NET language bindings.