dll

64位Unity集成亲加(gotye)即时通讯SDK时的editor动态库设置DllNotFoundException

2017年02月27日 0, ? C#, dotNet 设计开发

最近在测试亲加的语音聊天SDK(版本：gotyeapi_ex_v3.0_20170121_u3d.zip)，由于直接提供了Unity版本的插件实现，简化了用Unity引擎开发的App集成时的难度，尤其还提供了Windows平台的实现，可在Editor环境下直接测试大部分功能，这是大部分平台相关SDK所不具备的！在实际测试中，发现了一些官方文档中没有说明的小问题，特记录于此。
首先，下载的zip并没有像官方文档中描述的一样，只有一个unitypackage，这点影响不大，直接解开zip中的内容，复制所有cs文件到项目中即可，后面根据官方文档上的指引，windows平台需要将对应32位或64位版本的Plugins中的dll复制到Unity安装路径的Editor下，也就是Unity编辑器执行文件所在的位置。这点要注意并不是常规的项目中的Plugins路径！操作完成后，项目中加入初始化代码，然后运行，出现了官方文档中提到的“win64下的U3D的DLL找不到”的问题：

DllNotFoundException: gotyeapi
gotye.GotyeAPI..ctor () (at Assets/gotye/GotyeAPI.cs:52)
(wrapper remoting-invoke-with-check) gotye.GotyeAPI:.ctor ()
gotye.GotyeAPI.GetInstance () (at Assets/gotye/GotyeAPI.cs:122)

Continue reading…

VC++项目中第三方库代码生成std::string对象的析构崩溃问题

2016年09月2日 0, ? C, C++, Obj-C 设计开发

在使用预编译好的第三方库时，一定要注意生成库时的Runtime Library运行时库是否与引用库项目所使用的一致，一般提供prebuilt库方都会按照这些规则给库文件命名，如mt、mt-d等。
这次在测试一个别人提供好的mongo库时，就遇到了由于运行时库不一致导致的莫名其妙崩溃问题，崩溃代码如下：

mongo::BSONObjBuilder builder;
builder.append("type", 2)
mongo::BSONObj obj = builder.obj();
obj.jsonString();

在jsonString()这一步，任何BSONObj的转std::string方法，如toString()等，构造出的std::string在析构时会导致崩溃，大致看了下是标准库中的析构函数内执行此处时触发的：

__CLR_OR_THIS_CALL ~basic_string()
    {   // destroy the string
    _Tidy(true);
    }

放开运行的话会提示堆已被破坏，修改了一些调用代码方式，无果，最后发现自行创建的std::string析构时执行同样逻辑没有问题，最终发现是由于dll库使用的是debug版运行时库，而主程序使用的是非debug运行时库所致，在VS中Configuration properties->C/C++->Code Generation->Runtime Library，选择一致的debug版运行时库后，问题解决。