如果说你编译的exe运行时报错: “尝试读取或写入受保护的内存.这通常指示其他内存已损坏” 这很有可能是你是以非托管的方式错误地引用了64位的API中去. 为什么会这样? 那你就要考虑VS的编译器选项 /platform VS编译目标platform有这样的3个选项:AnyCPU,x86和x64. 如果一个程序被编译成AnyCPU,那么程序将包含2套相同逻辑的程序,一套在32位系统上用,另一套在64位系统上用.问题的原因就在这里. 如果你是在32位系统上用AnyCPU编译了代码,那么代码调用的时

错误信息: "RazorEngine.Templating.TemplateCompilationException"类型的异常在 RazorEngine.NET4.0.dll 中发生,但未在用户代码中进行处理 其他信息: Unable to compile template. "object"不包含"username"的定义,并且找不到可接受类型为"object"的第一个参数的扩展方法"username"

private void CopyAndOverwriteMap() { //IObjectCopy接口变量申明 IObjectCopy objectCopy = new ObjectCopyClass(); //要Copy的对象 object toCopyMap = m_mapControl.Map; //复制要复制的对象 object copiedMap = objectCopy.Copy(toCopyMap); //要复制到的文件 object toOverwriteMap = axPag

“System.Exception”类型的异常在 NHibernate.dll 中发生,但未在用户代码中进行处理 其他信息: OCIEnvCreate 失败,返回代码为 -,但错误消息文本不可用. 如有适用于此异常的处理程序,该程序便可安全地继续运行. 这个是NHibernate没有配置好造成的,重新配置NHibernate即可

“System.OutOfMemoryException”类型的异常在 mscorlib.dll 中发生,但未在用户代码中进行处理 这个原因肯定不是因为程序内部的逻辑错误,或者别的什么情况. 想想,肯定是因为大量测试所带来的,大量声明占用了过多的内容,最后导致溢出了, 由这个可以想到,出现这个异常应该是: 1.有死循环,到最后使用内存过多而溢出了 2.大量声明,并没有有效的释放,而导致内存占用过多: 这个情况可以采用 a)GC 回收: b)声明为静态类: c)调整程序结构,保证流程之间的嵌套不会

“System.NullReferenceException”类型的异常在 App_Web_zo44wdaq.dll 中发生,但未在用户代码中进行处理 其他信息: 未将对象引用设置到对象的实例. 解决问题: return View( 这里不能为空  ); 为空时:用ViewBag.属性 ViewData["字段"]向前端传值 就不报错了:

这两天因为需要用到VS2012来生成一个DLL代码,但是之前并没有用过DLL相关的内容,从昨天开始尝试调试DLL的文件调用,起初笔者在网络上找到了3片采用VSXXX版本进行调试的例子,相关的内容见本人Blog在C++中调用DLL中的函数(1)(2)(3) 但是问题出现了,上面讲述的步骤很详细但是在自己运行的时候却会出现错误,于是今天在使用google“vs2012 c++调用dll”时,发现了一篇MSDN上的指南:http://msdn.microsoft.com/zh-cn/library/m

现在最常看见的关于DLL的问题就是如何在DLL中使用对话框,这是一个很普遍的关于如何在DLL中使用资源的问题.这里我们从Win32   DLL和MFC   DLL两个方面来分析并解决这个问题.           1．Win32   DLL               在Win32   DLL中使用对话框很简单,你只需要在你的DLL中添加对话框资源,而且可以在对话框上面设置你所需要的控件.然后使用DialogBox或者CreateDialog这两个函数(或相同作用的其它函数)来创建对话框,并定义

这两天因为需要用到VS2012来生成一个DLL代码,但是之前并没有用过DLL相关的内容,从昨天开始尝试调试DLL的文件调用,起初笔者在网络上找到了3片采用VSXXX版本进行调试的例子,相关的内容见本人Blog在C++中调用DLL中的函数(1)(2)(3) 但是问题出现了,上面讲述的步骤很详细但是在自己运行的时候却会出现错误,于是今天在使用google“vs2012 c++调用dll”时,发现了一篇MSDN上的指南:http://msdn.microsoft.com/zh-cn/library/m

转自:http://www.cnblogs.com/woshitianma/p/3683495.html 这两天因为需要用到VS2012来生成一个DLL代码,但是之前并没有用过DLL相关的内容,从昨天开始尝试调试DLL的文件调用,起初笔者在网络上找到了3片采用VSXXX版本进行调试的例子,相关的内容见本人Blog在C++中调用DLL中的函数(1)(2)(3) 但是问题出现了,上面讲述的步骤很详细但是在自己运行的时候却会出现错误,于是今天在使用google“vs2012 c++调用dll”时,发现

在项目开发中遇到了,python需要去调用一个动态链接库dll中的c++方法.这个方法的参数为一个指针类型的参数,一个bool类型参数, 在python中并未对数字类型进行区分. int LP_Agc ( double * a, bool b= true ) 所以在调用这个方法之前, 第一步要将python中的类型转换为c语言类型. 这个应该是python自带的 a = c_double(1.0) #同理 b = c_double(True) #python中还有c_int(),c_float(

asp.net 编译错误类型“同时存在于”不同的dll中. 出现这种错误大概有三种情况: 1.ASPX页面,一个*.ASPX,对应着一个*.cs文件,两者其实是一个文件,通过两者实现代码分离,每个*.aspx页面都引用着自身的CS文件:如果两个页面引用了相同得.CS文件,在发布得时候也会出现这种错误. 2.估计是在Bin里面还有一个老版本的DLL,而新版的DLL名字换掉了,新的覆盖不掉老的,并存在BIN里时,有可能会发生这种情况. 解决方案:把BIN里的手动删掉,C:\WINDOWS\Micro

最近的一个项目中遇到了调用别人的sdk接口(dll库)而传给我的是一个vector指针,用完之后还要我来删除的情况.这个过程中首先就是在我的exe中将其vector指针转为相应指针再获取vector中相应的数据问题,始终都获得不了正确的数据,要么就是一些非法的数据:另一个问题就是delete这个指针时候会产生相应异常(针对这个问题的思考:如果EXE和DLL都链接到DLL的C/C++运行期库,那么代码将能够很好地运行.但是,如果两个模块中的一个或者两个链接到静态C/C++运行期库,那delete的

使用VS2008,在项目属性中有一项MFC的使用,有三种设置: 1.使用标准Windows库 2.在共享DLL中使用MFC 3.在静态库中使用MFC          第一种顾名思义.        第二种指的是打包时一些MFC的DLL的内容没有被包含在EXE文件中,所以EXE文件较小,但是运行时要求系统中要有相关的DLL文件.        第三种是将DLL中的相关代码写进EXE文件中,文件较大,但是可以在没有相关DLL的机器上运行.        同时,如果程序本来是第二种方式,发给同事,在

DLL中调用约定和名称修饰(一) 调用约定(Calling Convention)是指在程序设计语言中为了实现函数调用而建立的一种协议.这种协议规定了该语言的函数中的参数传送方式.参数是否可变和由谁来处理堆栈等问题.不同的语言定义了不同的调用约定.   在C++中,为了允许操作符重载和函数重载,C++编译器往往按照某种规则改写每一个入口点的符号名,以便允许同一个名字(具有不同的参数类型或者是不同的作用域)有多个用法,而不会打破现有的基于C的链接器.这项技术通常被称为名称改编(Name Mangl

声明: 事先我已经自己动手写了一个简单的dll文件(myDLL.dll),C版接口的.并且用我前两篇有关DLL文章里面的方法,从dll中导出了导入库(.lib)文件,dll中有两个函数,原型如下:    void HelloWorld();     //函数内部调用Win32 API,功能是弹出一个helloworld提示框    int add(int a,int b);  //实现两个数相加,并返回结果 下面分别通过显示调用和隐式调用两种方法,来模拟Qt如何调用外部dll文件中的功能函数,f

1.dll的优点 代码复用是提高软件开发效率的重要途径.一般而言,只要某部分代码具有通用性,就可将它构造成相对独立的功能模块并在之后的项目中重复使用.比较常见的例子是各种应用程序框架,ATL.MFC等,它们都以源代码的形式发布.由于这种复用是“源码级别”的,源代码完全暴露给了程序员,因而称之为“白盒复用”.“白盒复用”的缺点比较多,总结起来有4点. 暴露了源代码:多份拷贝,造成存储浪费: 容易与程序员的“普通”代码发生命名冲突: 更新功能模块比较困难,不利于问题的模块化实现: 实际上,以上4点概

应用程序使用DLL可以采用两种方式: 一种是隐式链接,另一种是显式链接.在使用DLL之前首先要知道DLL中函数的结构信息. Visual C++6.0在VC\bin目录下提供了一个名为Dumpbin.exe的小程序,用它可以查看DLL文件中的函数结构.另外,Windows系统将遵循下面的搜索顺序来定位DLL: 1．包含EXE文件的目录, 2．进程的当前工作目录, 3．Windows系统目录, 4．Windows目录, 5．列在Path环境变量中的一系列目录. 1．隐式链接 隐式链接就是在程序开始

最近用WIN32 DLL,为了方便要用到MFC的一些库,又不想转工程,就网上找了很多方法,发现没有详细的介绍,有的也行不通,现在成功在WIN32 DLL中使用了MFC,记录一下以防以后用到忘记 一.修改预编译头文件(stdafx.h) 在stdafx.h文件中添加下面代码,包含一些MFC的头文件,这些可以在一个MFC工程中复制过来 #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // 某些 CString 构造函数将为显式的 #include <afxwin

  这几天写几个小程序练手,在准备将一个类导出时,发现还真不知道如果不用MFC的扩展DLL,是怎么导出的.但我知道dllexport可以导出函数和变量,而且MFC扩展DLL就算是使用了MFC的功能,但能否导出类应该也不是必须用MFC才能够做到,一定是有相应的机制可以实现.于是查了一下MSDN,发现这个机制简单的可怕,原来就和导出函数一样,把dllexport关键字加到类名前就可以了.估计和我一样的同学大有人在,把MSDN的相关文档翻译出来,附上我的注解,希望对大家有用. 评注程序均在Visual

项目需要,在MFC dll中使用了boost thread(<boost/thread.hpp>),LoadLibraryEx的时候出现断言错误,去掉thread库引用后断言消失. 百度google后,在CSDN中找到一个答案,先贴出来: { boost::thread + MFC DLL 問題 基本上這個問題在boost 1.38就有了,只是沒想到更新成boost 1.45後問題還是沒有解決...  如果是使用MFC开发程序 ,又剛好建立的MFC DLL工程中有使用boost::thread