Membase CouchDB 无法在 Mac OS X 上与 Mono 一起使用
我已经成功安装了Membase Server,他们的“亚毫秒级访问延迟”特性实际上是迫使我写这个问题的,否则我十次已经改用MongoDB了。所以问题是:我已经正确安装和配置了我的 Membase 服务器,现在我希望我的 .NET 客户端应用程序能够访问该数据库,为此我正在使用他们的 Enyim .NET 客户端。我编写了以下测试应用程序:
using System;
using System.Linq;
using System.Diagnostics;
using Membase;
using Membase.Configuration;
namespace CouchDB
{
class MainClass
{
public static void Main(string[] args)
{
var config = new MembaseClientConfiguration()
{
Bucket = "helloworld",
BucketPassword = "123",
NodeLocator = typeof(Enyim.Caching.Memcached.DefaultNodeLocator),
Transcoder = new Enyim.Caching.Memcached.DefaultTranscoder(),
KeyTransformer = new Enyim.Caching.Memcached.TigerHashKeyTransformer(),
PerformanceMonitorFactory = null // I'm on Mac OS X
};
config.SocketPool.MinPoolSize = 10;
config.SocketPool.MaxPoolSize = 20;
config.SocketPool.DeadTimeout = TimeSpan.FromSeconds(10);
config.SocketPool.ConnectionTimeout = TimeSpan.FromSeconds(5);
config.Urls.Add(new Uri("http://localhost:8091/pools/default"));
var client = new MembaseClient(config);
var spoon = client.Get<String>("Spoon");
Console.WriteLine(spoon);
}
}
}
当我尝试创建客户端时出现问题,发生异常,甚至不显示完整的堆栈,仅
告诉“无法从源类型转换为目标类型”
在 System.Web.Script 处 .Serialization.JavaScriptSerializer..ctor(resolver=null, registerConverters=false)
I've successfully installed Membase Server, their "Sub-millisecond access latency" feature is actually forced me to write this question, otherwise I would ten times already switched to MongoDB. So the question: I have properly installed and configured my Membase Server now I want my .NET client application to get access to this database, for this purpose I'm using their Enyim .NET Client. I have written the following test application:
using System;
using System.Linq;
using System.Diagnostics;
using Membase;
using Membase.Configuration;
namespace CouchDB
{
class MainClass
{
public static void Main(string[] args)
{
var config = new MembaseClientConfiguration()
{
Bucket = "helloworld",
BucketPassword = "123",
NodeLocator = typeof(Enyim.Caching.Memcached.DefaultNodeLocator),
Transcoder = new Enyim.Caching.Memcached.DefaultTranscoder(),
KeyTransformer = new Enyim.Caching.Memcached.TigerHashKeyTransformer(),
PerformanceMonitorFactory = null // I'm on Mac OS X
};
config.SocketPool.MinPoolSize = 10;
config.SocketPool.MaxPoolSize = 20;
config.SocketPool.DeadTimeout = TimeSpan.FromSeconds(10);
config.SocketPool.ConnectionTimeout = TimeSpan.FromSeconds(5);
config.Urls.Add(new Uri("http://localhost:8091/pools/default"));
var client = new MembaseClient(config);
var spoon = client.Get<String>("Spoon");
Console.WriteLine(spoon);
}
}
}
The problem occurs when I'm trying to create a client, exception occurs which doesn't even show complete stack, tells only
"Cannot cast from source type to destination type"
at System.Web.Script.Serialization.JavaScriptSerializer..ctor(resolver=null, registerConverters=false)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我花了几个小时来解决这个问题。 Mono 运行时中存在错误(据我所知,它仍然存在于 2.10.5 中) ),这会导致两个版本的 System.Web.Extensions 之间发生冲突:3.5 和 4.0
为 Membase 客户端(现在是 Couchbase 客户端)提供的 DLL 与3.5版本。我不知道什么引用了 4.0 版本,但仍然有一些东西。所以解决方案是要么应用重定向(我没有测试过):
要么重新编译客户端(这就是我所做的)。在 mono 下编译客户端时有两个小问题:在 MemcachedNode.cs 中,有 Failed 事件的显式实现。由于它是不必要的(没有实现其他冲突的 Failed 事件),因此您可以删除这些行。还有一个 SetTcpKeepAlive 可以删除(我认为它是安全的)。
I've spent some hours on this problem. There is a bug in the Mono runtime (it's still present in 2.10.5 AFAIK), that causes a conflict between two versions of System.Web.Extensions : 3.5 and 4.0
The DLL provided for Membase client (and now Couchbase client) are linked with the 3.5 version. I don't know what references the 4.0 version, but still, something does. So the solution is either to apply a redirection (I haven't tested it) :
Or recompile the client (that's what I've done). There are two minor problems when compiling the client under mono : in MemcachedNode.cs, there is an explicit implementation of the Failed event. Since it is unnecessary (there is no other conflicting Failed event implemented), you can just remove the lines. Also there is a SetTcpKeepAlive that you can remove (I think it's safe).