As with all entries in this series, the up to date code and history can be found in Github at http://github.com/robashton/RavenGallery/
Where do I get RavenDB?
RavenDB can be downloaded from a number of places, you can download the stable binaries, the unstable binaries or go direct to Github and use whatever fork you find there.
I personally run off my own fork which is updated very frequently from Ayende’s code – as it means I can rapidly add any missing features and push them back or fix bugs when I find them.
For this project I’ll be doing just that, and the binaries found in the Image Gallery project will be from my fork found at http://github.com/robashton/Ravendb
This is because I’ll be utilising functionality that is on the bleeding edge of RavenDB, of course by the time most of you read this they’ll be in the released binaries, so we’ll move to those now.
Released builds (Unstable)
Next up on the stability list are the recent builds, which can be found on the Hibernating Rhinos site http://builds.hibernatingrhinos.com/builds/RavenDB-Unstable, this is probably safer than constantly pulling from Ayende’s fork and represent the latest changes that have made it through code review.
Released builds (Commercial)
At time of writing, these are about 20 builds behind the Unstable branch, and as such miss out on some of the functionality that can be enjoyed in the Unstable and code versions of RavenDB. Unless you are planning on releasing software in the next week or two, I don’t really advocate using this branch for development.
RavenDB is changing constantly, breaking changes still happen, API changes still happen, functionality is being added constantly – I have a suite of tests for all my projects that utilise RavenDB and I test all of my interaction with RavenDB.
By updating regularly I ensure that the amount of work needed to fix any breaking changes is kept to a minimum, as opposed to waiting 30 builds and finding out that half of my entire test suite fails.
That’s not to say that Raven isn’t ready for production because I believe that the stable branch is indeed stable, but because I’m in development and I haven’t got imminent release to look forward to I’m happy to put up with a few bugs in order to get the latest and greatest functionality.
The Project itself
Here is my solution
And this is what I meant by setting the .NET profile
Which RavenDB Binaries to use?
Once you’ve selected which binary drop to use, you have to make a decision as to which Raven.Client to use, and this is where I tell you why I made sure my Target Framework was set to 4
As my choice of target framework will tell you, I have chosen to host RavenDB internally as part of the web application, and I will take the responsibility for starting up and shutting it down as part of the application lifecycle.
The .NET Framework 4 profile is important, as it is a common gotcha for people to link the wrong binaries and wonder why they are still getting reference errors.
That’s set-up covered, in the next entry I shall cover how we’ll be hosting RavenDB in the application and managing our sessions with it.
But chances are I'm not available, as I'm busy shipping stuff.
I am available for conference speaking, I like talking and will do so for just T&E (and perhaps a bottle of wine or two).
I have done soft keynotes, and usually entertain/rile people in equal proportion, but prefer to talk tech as that's what I do