I found a C#/.NET version of a program that does something similar to what Miguel de Icaza’s Gecko# code does (albeit with a lot more features, and more desktop-oriented focus). It’s called Cropper, and is a program developed by Brian Scott and hosted at CodePlex under a shared-source license called the Microsoft Reciprocal License (Ms-RL, formerly called the Microsoft Community License). Aha, thinks me, this is just what I was looking for. (Why are you looking to do this, again? – ed. I don’t know. I’m like a dog with a bone.)
So of course there are a few problems. This has really been no better than the Mono/Gtk#/Gecko# experience, except as a .NET developer I would have been expecting an easier time of it. Here’s what happened:
- The source-control bindings are present in the source code download .zip file. Not a major problem, but annoying.
- There are duplicate zero-byte folders in the distro that prompt you for an “Overwrite?” confirmation. Is this some problem with the zip process? Odd. Also annoying.
- No README file. How the hell am I supposed to build/install this thing? I’m a .NET dev by trade, so it took me 2 seconds to figure out the deployment build, which creates your .MSI Windows Installer, but this is a big annoyance for anyone not used to the code. (UPDATE: the CropperSetup project contains a ReadMe.htm file, but it’s effectively buried from a new-user point of view)
- Biggest problem: When I run Cropper from Start|Program Files, I get the following error:
When I debug using the Microsoft CLR Debugger, I see:
Look familiar? This is the same error I got with my Gecko# test project earlier today. So I can figure out what it’s looking for via the Assembly Bind Failure Logging stuff I figured out earlier: Only this time running cropper from the command line doesn’t give me any log output at all. Running FUSLOGVW.EXE from the command line as per the original MSFT article doesn’t show anything either. Rebuilding with Release (instead of AutomatedRelease, which gave me the .MSI) and running from the \bin\release\ directory didn’t work either. Manually copying the missing assembly from the build directory to the installation directory didn’t work. At this point, I’m thinking WTF? Do I have to rebuild the deployment project from scratch? How much time should I spend on this anyway?
Funny thing: when I debug the error in the VS 2005 Debugger, and not the CLR debugger, I get:
This is why companies like Krugle will have a tough time. Source code is great; free source code is fantastic; but the SCM aspects of it can be a real pain in the ass. Add in abandonware issues with free source and you’re looking at real potential problems.