FirefoxDriver with C# / Mono does not work

[debuglevel]

There is actually an existing bug report (https://code.google.com/p/selenium/issues/detail?id=3804), but I did not know if anybody would notice my reply there.

Summary:
IWebDriver Driver = new FirefoxDriver(); does not work for Mono, as the DotNetZip library (https://dotnetzip.codeplex.com/) is not platform independent and uses backslashes instead of Path.DirectorySeperator. This results in an exception:

System.ArgumentException: Path is empty
  at System.IO.Directory.CreateDirectory (System.String path) [0x00000] in <filename unknown>:0 
  at Ionic.Zip.ZipEntry.InternalExtract (System.String baseDir, System.IO.Stream outstream, System.String password) [0x00000] in <filename unknown>:0 

Actually, there is already a patch created by user moonverma, which should fix this issue (https://www.codeplex.com/Download?ProjectName=dotnetzip&DownloadId=905384). Unfortunately, it does not seem that there will be any new release soon (last update: 2011, and a bunch of open patches and issues).

To make a long story short, have you ever thought of providing a patched version of DotNetZip to enable FirefoxDriver in Mono?

[jimevans]

There is no appropriate DotNetZip replacement or fork that has the issue properly patched and built. The canonical repository at CodePlex has not been updated since 2011, and is largely abandoned by its maintainer. It's not possible to simply patch-and-build that project, as the developer has neglected to supply the private key necessary to give the resulting assembly a strong name. Unfortunately, one of the release mechanisms of the .NET bindings is a strong-named assembly, which requires all referenced assemblies to be similarly strong-named. Note carefully that this also removes from consideration the most popular fork of the CodePlex repository, available at http://github.com/haf/DotNetZip.Semverd, as this fork expressly does not include a strong-named release artifact.

Our options are:

• Wait and hope that @DinoChiesa decides to resume updating the canonical repository on CodePlex, or ports to GitHub. I suspect this to be highly unlikely.
• Hope to convince @haf to provide strong-named assemblies. This is somewhat unlikely, though might be possible.
• Fork one of the two repositories, and sign and build our own version. This is a road that I personally don't have time to travel down and maintain.
• Develop our own, independent .NET ZIP archive library that can be incorporated as source code into the WebDriver project. Do I really need to describe how mind-numbingly foolish that approach would be?

There are no good options here, or at least none that don't significantly increase the maintenance overhead of the .NET bindings. Of course, if we could assume everyone used .NET 4.5, we'd be golden, but we can't make that assumption.

So to answer the question a the end of the issue report, yes, we've thought about it, and decided patching and building and maintaining a new fork of DotNetZip isn't an appropriate thing to do. Know that we will be looking out for other ways to resolve the issue, but in the meantime, I'm closing this one, as there's nothing we can really do at the moment to solve it.

[debuglevel]

Okay, thank you for this insights! :)

[haf]

@jimevans I have absolutely no problem signing it, that's what I do with github.com/logary for the obvious reasons.

I've stated this:

• I haven't got their previous signing key, so I can't sign it anew with theirs
• I'm looking for help to maintain it, but I merge and release all PRs that people care enough to do
• If you make a PR with code that signs the build, I will run it and publish the signed build
• I currently don't have a Windows machine, so for Windows-specific stuff (which admittedly isn't much), I need cooperation from the community to make it happen

So just send me a PR and I'll release it. Thx for atting me.

[haf]

And about the cross-platform stuff; the more you PR the better it gets.

It would be a good idea to actually have a productive discussion about what purpose DotNetZip serves now that compression streams are in the core framework inside both .Net and mono. DotNetZip has some extra features, but its code is fairly badly written, so it's hard to maintain.

I'm open for inputs. The code is what you all make of it.

[haf]

PS; you can poach Logary's signing code, because it works cross-platform and it's all nicely done with the Rakefile. Just copy-n-paste.

[jimevans]

@haf There's already a pull request on your fork of the project that would provide everything we need for our project. Integrating that pull request would likely be sufficient for the Selenium project. Incidentally, do you release binary versions of the assembly in any forum except for NuGet? Our project doesn't use NuGet, and won't do so anytime in the near future, so a simple downloadable binary release would be ideal.

As for the utility of the library going forward, I know the Selenium project needs to support users who are using versions 3.5 and 4.0 of the .NET Framework. Given that, fully migrating to the 4.5 System.IO.Compression libraries entirely is a non-starter at present. I wish we could move to them, because that would simplify things considerably. Alas, that's not the case.

[haf]

Yes, I can merge that: he never said he had gone through and signed all assemblies.

[haf]

Currently failing compilation: are you interested in helping out to make it compile on mono?

haf/DotNetZip.Semverd#35

Make it compile and I will publish another release. =)

[jimevans]

@haf I have no need for the library to compile on Mono. Does your fork require Mono compilation? I'm able to compile the library after the pull request, and build with no issues on a Windows VM running the .NET Framework. Once the assembly has been compiled using the .NET Framework, we should be able to use it on both Mono and .NET.

[haf]

@jimevans I don't have a legal Windows VM, and no intention of forking out the cash to build one. I could use modern.ie and spend a couple of hours automating the setup for when those boxes expire, but it's not worth the 1h+ wait for VS, .Net etc to install on a fresh installation, not to mention the 3+ hours for all updates to apply unless I use the very latest Windows. That's why I need mono compilation to work.

So I have three suggestions for ways forward:

• sponsor me with a Windows license and a Windows-machine for building + MSDN (unlikely, right?)
• help out; I give @jimevans commit access to both the repo and the nuget and you can compile it and help me maintain it
• help out; so that it compiles on mono

What do you say?

[jimevans]

I'm happy to help as far as I can. I'm not willing[1] to take on responsibility of maintain another high profile open-source project at present. I suppose I'm forced to wonder how the DotNetZip project compiled under Mono in the first place, before the merge of the pull request in question. Unless it never did, and the fact that there were previous releases at all were due to the largesse of other maintainers of the project, or because you, @haf, had access to a Windows machine at the time of the last release in June 2014. I'm not trying to be difficult; I'm simply trying to come up to speed on the project history to attempt to be able to make a meaningful contribution.

[1] I'm actually unable to make the time for that kind of sustained effort, but since "unable" is often not acceptable as a response, I'll simply own up to being unwilling to sign up for the additional responsibility.

[haf]

I had access to a Windows machine previous to starting my own product company.