How to make System.Data.SQLite.dll work on a 64 bit Windows server

I have a pet project in which I’m using SQLite for persisting day-to-day gasoline prices from various companies. No-one ever thought about that one, right? If this was 2001 I would have at least 20 employees and millions of venture capital already… Luckily this is 2011 and I’m not wasting anybody’s time and money on this one.

Anyway – I’m using SQLite as a persisting mechanism and I had a great deal of trouble making it work. I am for various reasons currently working on a 32 bit Windows 7 laptop and my production server is (luckily) a 64 bit Windows 2008 server. Everything worked fine on my laptop but once I deployed my solution to the server I got various error all evolving around an error message “Unable to load dll SQLite.Interop.dll”.

I thought at first that I just needed to adjust my Visual Studio project settings so all projects in my solution would build as 32 bit. That should work because as they say on MSDN: “If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR”

Short story was: I tried every possible combination of platform targeting, I tried deploying my code with both the 32 bit and 64 bit System.Data.SQLite.dll, I tried just about anything but never made anything work – and I really couldn’t figure out why because it ought to work but didn’t.

After digging for a while I realized that SQLite for .NET is simply a wrapper on top of the original C++ implementation… A few clicks verifying what had to be missing on the server 5 minutes later I had installed the 32bit Visual C++ package and everything started working.

The morale here is: I had a rock-solid idea about SQLite.Net that it wasn’t a wrapper around native code but was SQLite written in pure .NET but never confirmed it by looking it up. I’ve done it before and I’ll probably end up there again in the future but it is always a good idea spending a few minutes learning about the architecture of the tools you’re about to embrace as part of your toolbox. Had I learned from the beginning that there was a C++ assembly hidden somewhere I wouldn’t have spent an entire evening grinding teeth at my computer… Lesson learned this time for sure.

Using Jint to unittest your Javascript in C#

I recently stumbled across Jint and found it interesting to a degree that I have spent a few hours getting to know the product. 99 times out of 100 I don’t have the time or the energy to dig deeper into new products but the timing was well so off I went.

What is Jint? It is an opensource implementation of a Javascript interpreter. The project defines itself in the following terms: “Jint is a script engine based on the Javascript language…Jint aims at providing every JavaScript functionalities to .NET applications”. Does this mean that I can take a piece of Javascript and execute it in a .NET Console application? Yes it does – and it works out to be a much more frictionless experience than you might expect. I tried integrating QUnit with CruiseControl.NET a while back to test Javascript in a managed environment and even though I made it work 95% it really didn’t feel like a comfortable way to go. Let’s see some code (example is from the project’s website)

script= @"
  function square(x) { 
    return x * x; 
  };
  
  return square(number);
  ";
  
var result = new JintEngine()
  .SetParameter("number", 3)
  .Run(script));

Assert.AreEqual(9, result);

Really?  Yes, indeed… I decided to try it out on one of our own internal Javascript API methods and came up with this

[TestMethod]
public void Basic_GetRestHost_ValueReturned()
{
    string expectedValue = "http://restservices.localhost";

    var jint = new JintEngine();
    var returnVal = jint.Run(File.ReadAllText("dgiapi.js") + "return $dgi.getRestHost();");

    Assert.AreEqual(expectedValue, returnVal);
}

Test passes, 4 lines of code, not too much ceremony along the way… It took a while to figure out that the Run-method isn’t chained – I thought I could preload our API in a base class and use a second “Run” method to invoke the call to $dgi.getRestHost() but never made it work. It might not be best practise – it probably isn’t but haven’t dug deeper there yet.

Conclusion: Jint really looks promising. One of the major showstoppers along the way of testing Javascript for me has always been the lack of integration with buildservers and Continuous Integration but Jint seems to close the gap here. I can definately see some usages in our business here where we spend more and more of our time writing Javascript instead of serverside .NET code – especially because we’re currently migrating from a self-breed internal business application to a new, shiny installation of Microsoft xRM in which we will inevitably end up with Javascript to extend the standard user interface (hide buttons, load data into dropdowns etc. etc). It is business critical that these scripts works like expected so it would be nice to be able to unittest at least parts of them in a Continuous Integration environment. I’ll look forward to a PoC of Jint under these circumstances.

The project is work in progress and I submitted a bug yesterday - it was fixed this morning in a dev branch. Thumbs up.