【结果很简单,过程很艰辛】记阿里云Ons消息队列服务.NET接口填坑过程

Maybe 这个问题很简单，因为解决方法是非常简单，但填坑过程会把人逼疯，在阿里云ONS工作人员、同事和朋友的协助下，经过一天的调试和瞎捣鼓，终于解决了这个坑，把问题记下来，也许更多人在碰到类似问题的时候，会开放思路。当然不得不说，Ons的.NET接口还很不完善，甚至没有独立在Windos 2008/2012服务器测试过，希望官方加把力。

1、阿里云ONS介绍

ONS(Open Notification Service)即开放消息服务，是基于阿里开源消息中间件MetaQ（RocketMQ）打造的一款云消息产品，历经多次天猫双十一海量消息考验，在阿里巴巴内部有1000+个应用在使用，产品成熟稳定可靠， 是构建大型分布式系统的核心组件之一。它能为分布式应用系统提供异步解耦、削峰填谷能力，同时也具有海量消息堆积，高吞吐，可靠重试等互联网应用所需特性。从2014年10月至今开始对外公测，目前ONS提供了北京，青岛，杭州三大Region的高可用集群（产品稳定性及可用性完全按照阿里巴巴内部标准来实施，无单点，99.99%的高可用性），公测期间完全免费。

目前支持Java,C++,.NET, PHP四种语言，Linux平台下支持C++,JAVA和PHP三种语言, Windows平台支持C++和.NET两种语言。

2、系统环境、问题和解决过程

总的来说，虽然官方的Demo很简单，说明文档也不详细，连参数也没解释清楚，和Java的接口差距很大，但是自己选择的路，含着泪也要走完，既然项目已经选择了.NET，那就上吧。经过同事刘哥的前期尝试，我拿过来之后，做为消息消费者，开发是非常顺利的，只是在测试机测试的时候，碰到数据问题，经过努力，自己将真实数据模拟一下，也能解决。一切都很顺其自然，当所有测试完成，准备去正式环境测试的时候，问题接踵而至。。。。

开发环境：Win10 + .NET 4.0 + VS2013 ,目标平台：x86

测试环境：虚拟机-Windows Server 2008 R2 + .NET 4.0 + x64

测试程序本地是完全没有问题，所以兴高采烈拿去服务器，马上就出现下面的问题：

说明：ManagedONS.dll就是Ons的.NET接口，这个错误以前也遇到过，猜测可能是自己疏忽目标平台编译错误，因为是在64bit环境下使用32bit程序。

结果总么修改还是不行，由于我部署的Windows服务程序，怕有错误，马上拖了一个控制台去测试，还是同样的问题。。。。搜索了很多，也总结了一下：

Why：开发机也是64，没问题，为什么服务器不行，肯定是环境问题，环境差距在哪里？貌似也就是多了一个VS，然后我把本机的控制面板打开，看看那些是和开发环境相关的，如下图所示：

由于Ons的.NET接口是C++编写的，后来才知道是C++/CLI编写的，所以首先就怀疑Visual C++2012 Redistribution这个东西，马上去下载了一个相同版本的东西，安装下来，还是不行，杯具的是，后来才注意的，(我安装的版本是11.0.5XXX，实际上安装11.0.6XX也是不行的，原因不明，看下面分解)>。

各种折腾，问题依旧，我马上找了几个分析程序集依赖的工具，看看到底和哪些dll相关，找出来Copy进去就好了，想法是好的，但使用了好几个工具，如exescope，Dependency Walker等等，查找一遍后，确认该有的文件，服务器都有。。。。无果。。。 各种折腾都不行后，我只能向Ons官方旺旺群求助，他们的响应速度还可以，马上有一个技术人员和我联系，寻找问题和解决方法。首先阿里的技术人员对照说明文档让我核实了一些步骤，都没有问题，然后让我修改项目属性，分析所有dll的最低支持系统版本等等，最后让我把项目配置都该为X86+Release,结果这次出现的是这个问题：

　　是找不到指定模块。。。。毫无疑问，还是环境问题，经过我和同事刘哥的确认，Win10开发机，以及Win7的开发机都是可以运行的，最后我们迫不得已，正好刘哥电脑有一个Win 2012的虚拟机也是同样的问题，为了验证我们的想法，直接在虚拟机上安装了一个VS2013，真的是泪流满面。。。VS2013安装到一半，马上就OK了，我们马上打开控制面板，看看多了哪些东西，和最上面还是一样的，多了Visual C++2012 Redistribution，马上我们把这个东西对应的版本重新安装了一半到开发机，版本号是：11.0.6，兴高采烈，结果还是失望，难道是传说中的日了狗了。。。

　　Win2012虚拟机安装VS2013的确是可以运行，卸载后就又歇菜了。无奈，怀着沉重的心情，我们去吃了晚饭，回来后向新生命群的C++/CLI大神 石头求助，把Ons的相关文件发过去后，他反编译了一下，马上给我发过来一个 更高版本的 运行时版本：12.0.3，就是下面这个鬼，

我很纳闷，因为前面试了几个版本都不行，也不知道这个行不行，但是还是充满希望的安装上去，果然，一切OK。。。。。心情舒畅了，只能由衷的感谢。最后将解决方法发给了阿里的技术人员，希望他们写更完善的文档，不然开放测试服务，只会让更多的人充当小白鼠。。。

3、资源与工具

　　至今不懂为什么开发机的版本安装上去不行，但高一个版本就可以。时间紧迫，解决问题就好了吧。为了解决这个问题，看到一篇文章，非常不错，推荐给大家，虽然没从其中找到问题，但也学了不少东西，今天可算是把system32的文件翻了底朝天：

dll文件32位64位检测工具以及Windows文件夹SysWow64的坑

http://www.cnblogs.com/hbccdf/p/dllchecktoolandsyswow64.html

其中有一个检测Win32和64位dll文件的代码，为了检测自己的dll，特别把该博客的代码抠下来，做了一个winform工具，一起都留下来吧。核心代码如下：

private void button1_Click(object sender, EventArgs e)
{
	string path = System.Environment.CurrentDirectory;
	DirectoryInfo directory = new DirectoryInfo(path);
	FileInfo[] fileInfoArray = directory.GetFiles();
	StringBuilder sb = new StringBuilder ();
	foreach (var item in fileInfoArray)
	{
		String str = String.Format("{0}:  {1}",item.Name,IsPE32(item.FullName)? "32bit":"64bit");
		sb.AppendLine(str);
	}
	textBox1.Text = sb.ToString();
}

public static bool IsPE32(string path)
{
	FileStream stream = File.OpenRead(path);
	//移动到e_lfanew的位置处
	stream.Seek(0x40 - 4, SeekOrigin.Begin);
	byte[] buf = new byte[4];
	stream.Read(buf, 0, buf.Length);
	//根据e_lfanew的值计算出Machine的位置
	int pos = BitConverter.ToInt32(buf, 0) + 4;
	stream.Seek(pos, SeekOrigin.Begin);
	buf = new byte[2];
	stream.Read(buf, 0, buf.Length);
	//得到Machine的值，0x14C为32位，0x8664为64位
	Int16 machine = BitConverter.ToInt16(buf, 0);
	if (machine == 0x14C)
	{
		return true;
	}
	else
	{
		return false;
	}
}

界面如下，比较简陋，比较急着用，没有加工，大家自己看着办，使用方法是把程序拷贝到你要检测的程序集目录，如下图：

小工具源码在这里：FileDetect.rar