HtmlUnit wrapper for .NET (2.0b3)
1,710 views
Skip to first unread message
Jason
May 16, 2011, 4:12:20 AM5/16/11
to Selenium Developers
A contribution of a .NET driver for HtmlUnit based on Alpha 5 release
was offered by Mohammad "SahderOp" Abdulfatah back in August last
year.
Without knowing about that, I wrote some code which wraps HtmlUnit for
2.0b3 (current svn anyway). It can be used if you IKVM selenium
\client-combined-nodeps.jar (I used ikvm-0.46.0.1):
\ikvm\ikvm-0.46.0.1\bin\ikvmc -out:seleniumXJ.dll *.jar
and include a reference to that dll and the dlls required to support
it, including IKVM*.dll.
I IKVM'd Selenium Java in its entirety, not just the HtmlUnit
dependency, so my code is much simpler than Mohammad's (but at the
cost of more IKVM'd dlls).
Is there any interest in me opening an issue and attaching my code?
cheers .. Jason
[1] http://groups.google.com/group/selenium-developers/browse_thread/thread/f9a71c2969af4730
was offered by Mohammad "SahderOp" Abdulfatah back in August last
year.
Without knowing about that, I wrote some code which wraps HtmlUnit for
2.0b3 (current svn anyway). It can be used if you IKVM selenium
\client-combined-nodeps.jar (I used ikvm-0.46.0.1):
\ikvm\ikvm-0.46.0.1\bin\ikvmc -out:seleniumXJ.dll *.jar
and include a reference to that dll and the dlls required to support
it, including IKVM*.dll.
I IKVM'd Selenium Java in its entirety, not just the HtmlUnit
dependency, so my code is much simpler than Mohammad's (but at the
cost of more IKVM'd dlls).
Is there any interest in me opening an issue and attaching my code?
cheers .. Jason
[1] http://groups.google.com/group/selenium-developers/browse_thread/thread/f9a71c2969af4730
Jim Evans
May 16, 2011, 4:07:08 PM5/16/11
to Selenium Developers
-1 from me.
The issue with not building a .NET version of the HtmlUnit driver is
mainly that I'm loathe to take any more dependencies in the .NET
bindings. In the case of creating a .NET version of the HtmlUnit
driver, you're implying a dependency not only on a specific version of
HtmlUnit, but also a dependency on a specific version of IKVM.
I understand the appeal of wanting to use a "headless" browser for
testing. For the .NET bindings, though, I don't think HtmlUnit via
IKVM is the right choice for the core Selenium code. If you're dead-
set on using HtmlUnit as your headless browser of choice, you can
always use it via the RemoteWebDriver. And by all means, I encourage
you to post your code as part of your own open source project; you're
likely to find an audience with it, but I don't agree it belongs in
Selenium proper.
Of course, that's just one opinion. Others should chime in.
--Jim
> [1]http://groups.google.com/group/selenium-developers/browse_thread/thre...
The issue with not building a .NET version of the HtmlUnit driver is
mainly that I'm loathe to take any more dependencies in the .NET
bindings. In the case of creating a .NET version of the HtmlUnit
driver, you're implying a dependency not only on a specific version of
HtmlUnit, but also a dependency on a specific version of IKVM.
I understand the appeal of wanting to use a "headless" browser for
testing. For the .NET bindings, though, I don't think HtmlUnit via
IKVM is the right choice for the core Selenium code. If you're dead-
set on using HtmlUnit as your headless browser of choice, you can
always use it via the RemoteWebDriver. And by all means, I encourage
you to post your code as part of your own open source project; you're
likely to find an audience with it, but I don't agree it belongs in
Selenium proper.
Of course, that's just one opinion. Others should chime in.
--Jim
Paul Hammant
May 16, 2011, 4:10:23 PM5/16/11
to selenium-...@googlegroups.com
I think there's a question in there for Jason Harrop:
Which aspect of using HtmlUnit via RemoteWebDriver does not work for you, your company or client ?
- Paul
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
Jason
May 17, 2011, 3:00:13 AM5/17/11
to Selenium Developers
> Which aspect of using HtmlUnit via RemoteWebDriver does not work for you,
> your company or client ?
The company concerned baulked at introducing a J2EE app server into
> your company or client ?
what is otherwise a pure .NET testing environment.
Once you have the IKVM'd DLLs, the entire testing environment is
familiar to .NET devs, and runs entirely on the developer's machine.
Mark Collin
May 17, 2011, 4:08:16 AM5/17/11
to selenium-...@googlegroups.com
This may be a potential future candidate for the .NET bindings:
It's lacking JavaScript abilities at the moment but looks like it's in
progress. If nothing else a headless run without JavaScript could be
useful.
--
You received this message because you are subscribed to the Google Groups
"Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to
selenium-develo...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/selenium-developers?hl=en.
--
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
If you have received this email in error please notify postm...@ardescosolutions.com
Simon Stewart
May 17, 2011, 6:43:50 AM5/17/11
to selenium-...@googlegroups.com
On Tue, May 17, 2011 at 8:00 AM, Jason <jha...@gmail.com> wrote:
>> Which aspect of using HtmlUnit via RemoteWebDriver does not work for you,
>> your company or client ?
>
> The company concerned baulked at introducing a J2EE app server into
> what is otherwise a pure .NET testing environment.
>> Which aspect of using HtmlUnit via RemoteWebDriver does not work for you,
>> your company or client ?
>
> The company concerned baulked at introducing a J2EE app server into
> what is otherwise a pure .NET testing environment.
This is the core problem. It's best to think of the selenium server as
Just Another Binary. It happens to be implemented in Java, but that's
doesn't really matter once the tests are running.
Simon
Paul Hammant
May 17, 2011, 10:07:20 AM5/17/11
to selenium-...@googlegroups.com
On Tue, May 17, 2011 at 5:43 AM, Simon Stewart <simon.m...@gmail.com> wrote:
On Tue, May 17, 2011 at 8:00 AM, Jason <jha...@gmail.com> wrote:
>> Which aspect of using HtmlUnit via RemoteWebDriver does not work for you,
>> your company or client ?
>
> The company concerned baulked at introducing a J2EE app server into
> what is otherwise a pure .NET testing environment.
Jason, a nit-pick: it's a Java daemon process (J2SE), not a J2EE app server.
This is the core problem. It's best to think of the selenium server as
Just Another Binary. It happens to be implemented in Java, but that's
doesn't really matter once the tests are running.
As most on this list know the Selenium before Selenium RC, was 100% translated to all languages. This was popular for such communities but an immense burdon on the dev team.
We then introduced Selenium-RC, an generated language bindings. We feared that we'd lose the .Net community because of hard-line policies against non native technologies, and refusals to install J2SE on infrastructure. When we looked back after a year, we found our fears were mostly unfounded. Even the startup community around Ruby alike didn't have problems with treating Selenium-RC as a turn-key daemon.
Jason, is there any way that you could appeal to the infrastructure folks raising objections, and mollify them?
- Paul
Jim Evans
May 17, 2011, 11:49:07 AM5/17/11
to Selenium Developers
Warning: This is a long message catalogueing the state of so-called
"headless" browser solutions for the .NET world, tangentially
discussing other language platforms, and how well they do or don't
play with WebDriver. If this holds no appeal for you, you'd probably
do best to just skip this message altogether.
I'm going to piggyback off of this thread to expand on a point Mark
Collin brought up. There's really nothing quite like HtmlUnit in
the .NET space. I understand the impulse not to want to introduce
non-.NET stuff into the environment. I had many of the same concerns,
but I've come around to Simon's points of "it's Just Another Binary"
and "nobody actually browses the web with a headless browser".
However, I also realize that using a Java .jar isn't just an xcopy
deployment if you don't already have the Java runtime installed, and
in a "pure" (whatever that means) .NET shop, you may not.
Because of some institutional resistance to Java at some places, I've
spent some time looking into alternative "headless" projects. Here's a
summary of what I've found:
XBrowser[1] - I actually started a headless .NET browser called Crane,
but abandoned it when Nathan Ridley contacted me about his XBrowser
project. At one time, he was still using my .NET HTML parser. Good
chap, but very busy, and the .NET JavaScript implementations up to
this point haven't been up to the task, so no JS engine yet, and no
activity on the project in 6 months. One thing I learned while working
on the project is that creating a web browser is bloody *hard*. Feel
free to contact me off-list if you'd like to pick up the ball with
this one.
WebKitDriver[2] - This project is referenced on the Selenium project
Google Code home page, and uses a headless WebKit implementation. That
means it uses a "real" browser engine implementation as WebKit is used
by Safari and Chrome. The bad news is that it only has Java bindings,
and there seems to be little response to pressure from outside the
project to change that.
Envjs[3] - This is a JavaScript implementation, originally started by
John Resig (of jQuery fame). Needs a .NET JavaScript REPL and some
custom JavaScript work to be accessible from .NET.
Phantom.js[4] - Another headless WebKit implementation, but with a
JavaScript API, implemented as a C++ executable, compiled for specific
platforms. It's downside is that it doesn't act as a resident process
that you can communicate with and control. Rather, it runs a single
JavaScript script, then exits. Having said that, there is an issue in
their issue list to create a WebDriver-compliant driver, and the
project is under active development. Built statically, this would
amount to an xcopy-deployable project.
webdriver-zombie[5] - This is a WebDriver implementation built to
drive the Zombie.js headless browser. This project is brand-new. Like
the first commit was yesterday. It's based on node.js, which is
getting lots of pub lately. That doesn't help Windows users in the
slightest at present, but the node project has a stated goal of native
Windows support (experimental in 0.5, stable in 0.6), so there's
potential there. When (if) the native Windows support materializes for
node, this would also amount to an xcopy-deployable project.
So if an xcopy-deployable binary solution is okay with your dev
department, there are a couple of options under development that show
promise, even if they're not yet available. Contacting those project
owners and getting involved would probably speed up the process of
getting WebDriver-compliant drivers build and available. If you can
talk them into an installable solution, you can use HtmlUnit via
RemoteWebDriver today. If they're going to insist on a .NET-only
binary, you can continue down the path of your IKVM solution, or you
can write your own headless browser, maybe building on the foundation
of Crane/XBrowser. In any case, I wouldn't expect any of these
solutions to land in the WebDriver trunk anytime soon, but I suspect
the Selenium ecosystem is large enough to encompass other projects
that provide different implementations of the Selenium WebDriver APIs,
even as independent OSS projects.
Regards,
--Jim
[1] https://github.com/axefrog/XBrowser
[2] http://webkitdriver.googlecode.com/
[3] http://www.envjs.com/
[4] http://www.phantomjs.org/
[5] https://github.com/90kts/webdriver-zombie
On May 17, 10:07 am, Paul Hammant <p...@hammant.org> wrote:
> On Tue, May 17, 2011 at 5:43 AM, Simon Stewart <simon.m.stew...@gmail.com>wrote:
"headless" browser solutions for the .NET world, tangentially
discussing other language platforms, and how well they do or don't
play with WebDriver. If this holds no appeal for you, you'd probably
do best to just skip this message altogether.
I'm going to piggyback off of this thread to expand on a point Mark
Collin brought up. There's really nothing quite like HtmlUnit in
the .NET space. I understand the impulse not to want to introduce
non-.NET stuff into the environment. I had many of the same concerns,
but I've come around to Simon's points of "it's Just Another Binary"
and "nobody actually browses the web with a headless browser".
However, I also realize that using a Java .jar isn't just an xcopy
deployment if you don't already have the Java runtime installed, and
in a "pure" (whatever that means) .NET shop, you may not.
Because of some institutional resistance to Java at some places, I've
spent some time looking into alternative "headless" projects. Here's a
summary of what I've found:
XBrowser[1] - I actually started a headless .NET browser called Crane,
but abandoned it when Nathan Ridley contacted me about his XBrowser
project. At one time, he was still using my .NET HTML parser. Good
chap, but very busy, and the .NET JavaScript implementations up to
this point haven't been up to the task, so no JS engine yet, and no
activity on the project in 6 months. One thing I learned while working
on the project is that creating a web browser is bloody *hard*. Feel
free to contact me off-list if you'd like to pick up the ball with
this one.
WebKitDriver[2] - This project is referenced on the Selenium project
Google Code home page, and uses a headless WebKit implementation. That
means it uses a "real" browser engine implementation as WebKit is used
by Safari and Chrome. The bad news is that it only has Java bindings,
and there seems to be little response to pressure from outside the
project to change that.
Envjs[3] - This is a JavaScript implementation, originally started by
John Resig (of jQuery fame). Needs a .NET JavaScript REPL and some
custom JavaScript work to be accessible from .NET.
Phantom.js[4] - Another headless WebKit implementation, but with a
JavaScript API, implemented as a C++ executable, compiled for specific
platforms. It's downside is that it doesn't act as a resident process
that you can communicate with and control. Rather, it runs a single
JavaScript script, then exits. Having said that, there is an issue in
their issue list to create a WebDriver-compliant driver, and the
project is under active development. Built statically, this would
amount to an xcopy-deployable project.
webdriver-zombie[5] - This is a WebDriver implementation built to
drive the Zombie.js headless browser. This project is brand-new. Like
the first commit was yesterday. It's based on node.js, which is
getting lots of pub lately. That doesn't help Windows users in the
slightest at present, but the node project has a stated goal of native
Windows support (experimental in 0.5, stable in 0.6), so there's
potential there. When (if) the native Windows support materializes for
node, this would also amount to an xcopy-deployable project.
So if an xcopy-deployable binary solution is okay with your dev
department, there are a couple of options under development that show
promise, even if they're not yet available. Contacting those project
owners and getting involved would probably speed up the process of
getting WebDriver-compliant drivers build and available. If you can
talk them into an installable solution, you can use HtmlUnit via
RemoteWebDriver today. If they're going to insist on a .NET-only
binary, you can continue down the path of your IKVM solution, or you
can write your own headless browser, maybe building on the foundation
of Crane/XBrowser. In any case, I wouldn't expect any of these
solutions to land in the WebDriver trunk anytime soon, but I suspect
the Selenium ecosystem is large enough to encompass other projects
that provide different implementations of the Selenium WebDriver APIs,
even as independent OSS projects.
Regards,
--Jim
[1] https://github.com/axefrog/XBrowser
[2] http://webkitdriver.googlecode.com/
[3] http://www.envjs.com/
[4] http://www.phantomjs.org/
[5] https://github.com/90kts/webdriver-zombie
On May 17, 10:07 am, Paul Hammant <p...@hammant.org> wrote:
> On Tue, May 17, 2011 at 5:43 AM, Simon Stewart <simon.m.stew...@gmail.com>wrote:
Jason
May 21, 2011, 4:38:56 AM5/21/11
to Selenium Developers
OK thanks for the answers everyone.
I'm off that project now, so for me, asking about this was really just
a matter of providing the HtmlUnit wrapper if there was interest in
it :-)
I contemplated changing the code so that you pass in a driver name (eg
org.openqa.selenium.htmlunit.HtmlUnitDriver) as a string, and do
everything via reflection, so that you wouldn't need the IKVM'd dlls
at compile time. Falling out of that would be that you
could also run any of the other Java drivers the same way.
Anyway, if anyone reading this does want to put the code up on google
code as a little project, let me know.
cheers .. Jason
I'm off that project now, so for me, asking about this was really just
a matter of providing the HtmlUnit wrapper if there was interest in
it :-)
I contemplated changing the code so that you pass in a driver name (eg
org.openqa.selenium.htmlunit.HtmlUnitDriver) as a string, and do
everything via reflection, so that you wouldn't need the IKVM'd dlls
at compile time. Falling out of that would be that you
could also run any of the other Java drivers the same way.
Anyway, if anyone reading this does want to put the code up on google
code as a little project, let me know.
cheers .. Jason
Reply all
Reply to author
Forward
0 new messages