Couchbase .NET Client Library

This is the offical .NET client library for Couchbase Server.

Features:

The client currently provides support for Couchbase Server 1.8+.

• Understands both the binary and text protocols
• Highly configurable and extendable (custom configuration, serialization)
• Supports consistent hashing
• CheckAndSet operations
• Persistent connections for more speed
• SASL Authentication

Documentation

Documentation is maintained over at the Couchbase site. A good starting point for docs about the .Net client SDK is "Getting started with the Couchbase .Net client"

Requirements

You'll need .NET Framework 3.5 or later to use the precompiled binaries.

Distributed via NuGet

The client is distributed via NuGet, and to install it, just type:

PM> Install-Package CouchbaseNetClient

To get help started, read this introduction: "Getting started with the Couchbase .Net client"

Building the Client

Just clone your fork or the main repository:

git clone https://<your-user-name>@github.com/couchbase/couchbase-net-client

then locate and build the Couchbase.sln solution, using Visual Studio 2010 or later. The client uses NuGet package restore, hence any missing packages will be restored during the build, but you must ensure that your machine allows package restores.

Tests

By default the test project expects a local installation (localhost) of a Couchbase server. It should be configured to have a cluster user name: "Administrator" with password: "password".

Expected buckets are:

• "default"
• and a SASL enabled bucket, named: "authenticated" with the password: "secret".

To get the tests to run if you have a different setup then the above, just update values in the App.config file located in the test project Couchbase.Tests. E.g, lets say you have an installation running on a server alias cb1, then replace all http://localhost for http://cb1.

Getting Help

For help with the Couchbase .NET Client Library see the Couchbase SDK Forums.

Versioning Notes

We use the "Semantic Versioning 2.0" model described here for our versioning model: http://http://semver.org/ *All officially released binary's use the following convention: .. for example 1.2.9 or 1.3.0. *We occasionally provide snapshots of mid-iteration bug fixes for validation purposes. In which case we add another number ... where is a number starting at 5000 (e.g. 1.3.0.5000) and incremented with each build. *All snapshot builds are neither tested thoroughly nor supported in any way - user beware!