dll文件

在VS 2013中编译程序时出现错误： 错误提示1： error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] 原因 ： 常规里面是：在静态库中使用MFC,或使用标准Windows库，此时该处可能无论是什么都会报错 运行库中多线程调试是：MDd(多线程调试DLL) 解决方法 ： 将MDd改成MTd，如果改正后报错误2，按下面方法更改。 错误提示2： error C1189: #error： Please use the /MD switch for _AFXDLL builds 原因 ： 常规里面是：在共享DLL中使用MFC, 运行库中多线程调试是：MTd(多线程调试) 解决方法 ： 将常规改成：在静态库中使用MFC,或使用标准Windows库 常规和运行库 如下图： 常规： 右击项目->属性->配置属性->常规，然后在右边的“项目默认值”中的“MFC的使用”选项中选择“在静态库中使用MFC”， 多线程调试： 右击项目-->属性->配置属性->c/c++->代码生成->运行时库->多线程调试(/MTd) 相关注释： MFC的使用

了解BPL和DLL的关系将有助于我们更好地理解DELPHI在构件制作、运用和动态、静态编译的工作方式。对初学DELPHI但仍对DELPHI开发不甚清晰的朋友有一定帮助。 BPL vs. DLL (原文http://www.delphi3000.com/ 翻译：房客) 第一部分：有关包的介绍 一般我们编写编译一个DELPHI应用程序时，会产生一个EXE文件，也就是一个独立的WINDOWS应用程序。很重要的一点：区别于Visual Basic，DELPHI产生的是预先包裹的应用程序是不需要大量的运行库（DLL's）。 假设：打开Delphi默认的工程（只有一个空白form），F9她将编译生成一个大约295 KB (Delphi 5)的可执行文件。然后打开Project | Options，把‘Build with runtime packages’选上再编译一下，EXE文件大小就只有15 KB左右了。 我们编译一个DELPHI应用程序时默认地没有选择'Build with runtime packages'，编译器将把程序运行所需要的代码直接写入你的EXE文件中，因此产生的程序是一个相对独立的程序，并不需要任何附属的支持文件（例如动态运行库文件DLL），这也就知道了为什么DELPHI产生的应用程序为什么都那么大。 要建立尽可能小的DELPHI程序，方法之一就要充分发挥Borland

基于Delphi的融合DLL中的窗口 　 摘 　 要 ：提出了一种简单的方法将DLL中的窗口融合（嵌入）到其他应用程序或DLL的窗口中，使用本方法可以简便地实现具有强扩展性和升级能力的软件系统。 　　 1　引言 　　在开发一个大型通用控制系统时曾遇到这么一个问题：该系统软件包由若干个可执行文件和动态链接库组成，因为扩展性和兼容性的要求，需要将系统划分为若干个可执行文件和动态链接库，并且在大部分DLL中封装各自的操作界面，在调用DLL时将其中包含的部分界面嵌入地显示在主界面的某个区域或某个窗口内，与主界面的其他部分浑然一体。这样主程序与DLL在功能操作上各司其职，在外部界面上又彼此交融，使用户可以通过增加和修改DLL来实现对系统内部、外部的扩展和升级；同时因为DLL的跨语言特性，内部包含操作界面的DLL可以更为方便地在以后的不同工作、不同语言环境中更好地重复使用。 　　这一问题的应用较为广泛，但没有充分的资料来帮助解决，经过不断的试验，笔者将初步体会总结出来，用以抛砖引玉。本文中涉及的主程序和DLL都是在Delphi5．0下实现的，但因为其中所依赖的基础还是Windows本身的窗口机制，所以对于其他的语言平台也有实际意义。 　　在Delphi中如何创建DLL及输出DLL中的函数有较多资料进行过介绍，在本文中不再赘述，本文只针对DLL中的窗口部分做重点介绍。 2

　　在项目中突然降临一个异常，对于经验不足的我，没能果断找出原因，折腾了小半天，最后在网上查资料，死马当活马医，居然有效了.... 　　留个记录。 　　我遇到的错误如下： 　　提示某个DLL文件找不到或者它的某个依赖项找不到。原因是参数错误。 　　当时项目已经接近尾声，自测阶段突然机器死机，重启后再打开页面就一直卡在这个错误上，搞得我非常恼火,找了几个同事看了看，也没有明确的解决方案，最后在网上找到通过清理FrameWork缓存目录的方法解决。 　　清理： C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files 目录下的文件，重新Build项目，OK！ 来源： https://www.cnblogs.com/liver.wang/archive/2011/11/16/bug.html

第一部分：有关包的介绍 一般我们编写编译一个DELPHI应用程序时，会产生一个EXE文件，也就是一个独立的WINDOWS应用程序。很重要的一点：区别于Visual Basic，DELPHI产生的是预先包裹的应用程序是不需要大量的运行库（DLL's）。 假设：打开Delphi默认的工程（只有一个空白form），F9她将编译生成一个大约295 KB (Delphi 5)的可执行文件。然后打开Project | Options，把‘Build with runtime packages’选上再编译一下，EXE文件大小就只有15 KB左右了。 我们编译一个DELPHI应用程序时默认地没有选择'Build with runtime packages'，编译器将把程序运行所需要的代码直接写入你的EXE文件中，因此产生的程序是一个相对独立的程序，并不需要任何附属的支持文件（例如动态运行库文件DLL），这也就知道了为什么DELPHI产生的应用程序为什么都那么大。 要建立尽可能小的DELPHI程序，方法之一就要充分发挥Borland package libraries的作用，简称BPL。 先说什么是包？ 简而言之，一个包就是一个在DELPHI的IDE环境中被DELPHI应用程序共享的特殊的动态链接库。包允许我们通过多级应用将我们的程序的一部分当做一个分离的模块供其他应用程序来共享。

Windows下的动态链接 之 DLL简介 DLL简介 1.1 进程地址空间和内存管理 1.2 基地址和 相对地址（RVA） 1.3 DLL共享数据段 1.4 DLL 的简单例子 1.5 创建 DLL 1.6 使用 DLL 1.7 使用模块定义文件 1.8 DLL 显示运行时链接 DLL简介 DLL 即**动态链接库（Dynamic-Link Library）**的缩写，它相当于Linux下的共享对象。Window 系统大量采用了这种 DLL 机制，甚至包括 Windows 的内核的结构都很大程度依赖于 DLL 机制。Windows 下的 DLL 文件和 EXE 文件实际上是一个概念，它们都是有 PE 格式的二进制文件，稍微有些不同的是 PE 文件的头部中有个符号位表示该文件是 EXE 或者是 DLL，而 DLL 文件的扩展名不一定是.dll，也有可能是别的比如.ocx（OCX控件）或是.CPL（控制面板程序）。 DLL 的设计目的与共享对象有些出入，DLL 更加强调模块化，即微软希望通过 DLL 机制加强软件的模块化设计，使得各个模块之间能够松散的组合、重用和升级。所以我们在 Windows 平台上看到大量的大型软件设计都通过升级 DLL 的形式进行自我完善，微软经常将这些升级补丁积累到一定程度以后形成一个软件更新包（Service Packs）。比如我们常见的微软 Office

Q1：关于 VS2005 打包 Microsoft.mshtml 的解决方法 A1：在打包时出现了问题，Microsoft.mshtmal.dll 无法打入安装包，但 .NET Framework 2.0 又没有把这个 dll 安装到程序集的全局缓存。因此，就出现在装有 VS2005 的机器上程序运行正常，但安装到其他计算机上时出现找不到程序集的情况。这是因为在安装 VS2005 时，VS2005 安装程序会将这个 dll 安装到程序据全局缓存，打包时就不会再将该 dll 打到安装包中了。 解决的方法其实很简单，因为 Microsoft.mshtmal.dll 这个 dll 是从 system32 文件夹下的 mshtml.tlb（COM 类型库文件）中导出的，因此我们只需要用 VS2005 自带的 TlbImp.exe COM 类型库导出工具将这个 tlb 文件再导一遍就可以了。我使用下面的脚本进行导出： tlbimp mshtml.tlb /out:mshtml.dll 最后得到一个 mshtml.dll 程序集文件，将我们项目中引用的 Microsoft.mshtmal.dll 替换为 mshtml.dll，再打包时这个 dll 就可以被添加到安装项目中了。 来源： https://www.cnblogs.com/emily_fly/archive/2010/05/19

将修改后的webapi程序重新生成，重新生成后复制bing文件夹中的dll。用复制的dll文件覆盖发布的文件夹中bing下面的dll文件。 来源： https://www.cnblogs.com/my2020/p/12458095.html

有时候程序引用了一堆外部的dll，和可执行文件存在一起，显得很乱， 我就想把他们整理一下，分别放在不同的目录下。整理完，程序还 提示找不到dll了。 可以在config文件中指定搜索目录： <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="my_dll_path1;myDllPath2"/> </assemblyBinding> </runtime> 来源： https://www.cnblogs.com/sinceret/p/12448269.html

上篇文章实现了Qt+MinGW+Opencv+Zbar的配置。接下来，由于项目需求，需要用Java调用，因此需要将之前二维码识别的代码编译成Dll，供java调用。 1 Java调用Dll的方法 1.1 利用Java自带的JNI JNI是Java Native Interface的缩写，通过使用 Java本地接口书写程序，可以确保代码在不同的平台上方便移植。它允许Java代码和其他语言写的（本地已编译的）代码进行交，这样做通常会丧失平台可移植性。但是，有些情况下这样做是可以接受的，甚至是必须的。 基本流程是首先在java环境下，建立一个java的接口，然后利用Java自带的工具javah，将这个接口转换成C或C++类型的接口，然后，在VC或中Qt的环境下借助编译器，实现这个接口的功能，并编译成Dll。 在Java环境下通过调用这个Dll，就可以访问本地代码或已编译的库的功能， 这个方法的效率是最高的，缺点是由于对应于某一平台的 JNI 本地代码调用通常不能移植到其他平台上。 这种方法适用于核心代码大部分已经在本地完成，将代码重新写成Java的工作量复杂或者根本无法完成的情况，我们需要在本地用C++或C把这些代码封装起来供Java 使用，这个封装的Dll可以由我们指定实现某种功能，也就是说可以在保证Java代码不更改的情况下，改变程序的功能。 1.2 利用Java自带的JNA JNA