Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Couchbase .NET client library (official), based on the Enyim memcached client

NCBC-425: SetSocketOption throws exception under mono runtime

This fixes the bug that threw the exception and makes the LingerOptions an
optional configuration by adding lingerEnabled and lingerTime options to the
socketPool configuration in the app.config. The socket will use the
default linger options (as defined by the IP stack) if lingerEnabled is
false or not set in the configuration. If lingerEnabled is true and the
lingerTime value is specified is zero, then no linger time will be used.
If lingerEnabled is true and the lingerTime is greater than zero, the
linger time will be set to the value specified in the lingerTime option.
You can change these values like so in the App.Config:
<socketPool lingerEnabled=true lingerTime=00:00:10/>

Ref: LingerOption Class MSDN

Change-Id: If0cc540c077b59ab9684fd7b0b8559dac8e9b73e
Reviewed-on: http://review.couchbase.org/35163
Tested-by: Jeffry Morris <jeffrymorris@gmail.com>
Reviewed-by: Mark Nunberg <mnunberg@haskalah.org>
latest commit dc0d487aab
Jeffry Morris jeffrymorris authored
Octocat-spinner-32 build-utils NCBC-334: Add a method of getting the version of the library programa… January 06, 2014
Octocat-spinner-32 src NCBC-425: SetSocketOption throws exception under mono runtime April 11, 2014
Octocat-spinner-32 .gitignore NCBC-265: Refactor solution to include directly the Enyim dependencies May 24, 2013
Octocat-spinner-32 .gitmodules NCBC-265: Refactor solution to include directly the Enyim dependencies May 24, 2013
Octocat-spinner-32 Readme.mdown NCBC-345: Update Readme.mdown to reflect changes in our versioning po… December 13, 2013
Octocat-spinner-32 enyim-dev-prep.py Update dev prep script to make Enyim "SignAssembly" key false for loc… March 28, 2012
Readme.mdown

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!

Something went wrong with that request. Please try again.