(Code is here:
http://github.com/robashton/RavenGallery/ by the way )
BLOG ENTRY - SETTING UP THE PROJECT
Where do I get it 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.
Why unstable?
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
I’ve made an MVC2 project in VS2010 and removed all the default
garbage that gets provided with it, apart from the JavaScript files,
the CSS and the master page. I’m starting from a blank slate and
removing all the code because I know how much that offends people.
I’ve downloaded the following libraries: Moq, NUnit, StructureMap and
shoved them in a folder called _Libs along with the RavenDB binaries.
Oh yes, I’ve got a basic StructureMapControllerFactory that I’ll be
using to create controllers with dependencies injected (in case
anybody asks later on)
I’ve got two additional projects (class libraries) which are named
RavenGallery.Core and RavenGallery.Core.Tests
I’ve gone through the project settings and ensured their .NET profile
is set to .NET Framework 4
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
Raven.Client.Lightweight.dll
This is for when you are using .NET Framework 4 Client Profile
This doesn’t require any of the other binaries (Lucene/etc)
This doesn’t allow you to host RavenDB within your application
This is therefore a pure client
Raven.Client.3.5.dll
As the name suggests, this is for when you are still on the .NET 2.0
runtime (using the .NET 3.5 framework)
This doesn’t require any of the other binaries (Lucene/etc)
This doesn’t allow you to host RavenDB within your application
This is therefore a pure client for older versions of the .NET
framework
Raven.Client.dll
This is the full, heavyweight client for .NET 4.0 (not client
profile!)
This requires all of the other binaries (Lucene.NET, Esent, etc)
This allows you to host RavenDB within your application
This is a mixed client + server
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.