dll文件

前言 　　nuget 已经不是什么新东西，它是vs的一个扩展工具，可以让我们在项目中添加、删除、更新引用变得更加快捷方便。现在有许多传统公司对dll的管理还是很落后的，有些甚至时通过发送dll文件，这样做的直接缺点就是很繁琐、容易出错。之前就有试过一个dll的版本不对，测试人员更新到线上接口直接就挂了，接着就是花一堆时间定位问题。nuget可以让我们很方便的管理引用，减少许多不必要的麻烦。接下来就图文讲解一下如何在自己计算机、公司内部服务器，或者是nuget 服务器搭建自己的nuget库，本篇没有高级的东西，只对新手有参考价值。 搭建包服务器 1. 安装nuget工具 　　这个就很简单了，如果你的vs还没有那是不行的。直接在【工具】->【扩展和更新】 搜索一下nuget 即可安装，安装后在项目右键引用就会出现【管理Nuget程序包】菜单，在这里我们就可以安装所需要的引用，例如EF，Newtonsoft，jQuery 等等。下面的【程序包管理控制台】可以通过命令来安装引用，界面去操作是一样的。 　　 2. 搭建nuget服务器 　　nuget 服务器其实就是一个站点，通过请求去获取需要的包。所以我们需要做的就是搭建一个web站点。 　　我们新建一个asp.net mvc 项目，在【程序包管理器控制台】输入 Install-Package Nuget.Server -Version 2

参考： 【1】 【2】 【3】 【4】 菜鸟笔记： 先创建类库，再创建控制台应用程序进行引用 dll文件生成位置：bin-debug-.dll 项目-添加引用-浏览dll文件位置并添加 注意引用dlltest（using dlltest;） 生成解决方案 类库dlltest using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows.Forms; namespace dlltest { public class Class1 { public void ShowMessage() { Console.WriteLine("你调用了动态链接库！"); Console.ReadLine(); } } } 控制台应用程序ConsoleApplication using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using dlltest; namespace ConsoleApplication1 { class Program

DLL搜索路径和DLL劫持 环境：XP SP3 VS2005 作者：magictong 为什么要把DLL搜索路径（DLL ORDER）和DLL劫持（DLL Hajack）拿到一起讲呢？呵呵，其实没啥深意，仅仅是二者有因果关系而已。可以讲正是因为Windows系统下面DLL的搜索路径存在的漏洞才有了后来的一段时间的DLL劫持大肆流行。 最近（其实不是最近，哈，是以前分析过，断断续续的……）简单分析了一个DLL劫持下载者的行为，感觉有必要写点东西说明一下。其实DLL劫持是比较好预防的，从编程规范上我们可以进行规避（后面会专门讲到），从实时防护的角度来讲我们也可以想出一些办法进行拦截。新的DLL劫持者基本都是通过当前路径来入侵，一些老的DLL劫持者一般都是通过exe的安装目录来入侵的，为什么会这样，后面还会讲到。 要搞清DLL劫持的原理，首先要搞清DLL搜索路径，到哪去搞清？当然是问微软啦！MSDN上面有一篇专门讲DLL搜索顺序的文章（Dynamic-Link Library Search Order http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx），虽然是英文的但是并不复杂讲得很清楚，大家如果对这块兴趣大的话可以仔细研读下，我就不翻译了。 Dynamic-Link Library Search

以下示例以windbg加载calc.exe为例: 1 .!sym !sym 扩展控制显示详细的符号加载和符号提示。 .!sym : 不带参数表示显示当前的详细符号加载和符号提示的设置状态 给个示例: 0:001> !sym !sym <noisy/quiet - prompts/prompts off> - noisy mode - symbol prompts on 其实细心点可以看出sym的四种状态了, noisy / quiet - prompts /prompts off,所以我们要记这个命令的用法,就只要调用下!sym,就看到所有用法了.嘿嘿,我还比较聪明的 <>后面表示当前的设定状态, !sym noisy 激活详细符号加载(noisy symbol loading)显示。 给个示例: 0:001> !sym noisy noisy mode - symbol prompts on !sym quiet 禁止详细符号加载显示 0:001> !sym quiet quiet mode - symbol prompts on !sym prompts 当SymSrv 接收到认证请求时，允许弹出对话框。 0:001> !sym prompts quiet mode - symbol prompts on !sym prompts off

//首先生成一个my.dll项目，在cpp中添加如下代码 //导出函数 _declspec(dllexport) int test(int a, int b) { return a + b; } //生成my.dll和my.lib //并重新创建一个控制台项目，把my.dll和my.lib放到项目文件夹下 生成以下代码 #include <iostream> using namespace std; //连接lib文件 #pragma comment(lib,"my.lib") //导入函数 _declspec(dllimport) int test(int a, int b); int main() { while (1) { int a; int b; cout << "请输入2个整数\n"; cin >> a >> b; int aa = test(a, b); printf("%d\n", aa); } return 0; } 来源： https://www.cnblogs.com/shenji/p/12347086.html

项目中可能会经常用到第三方库，主要是出于程序效率考虑和节约开发时间避免重复造轮子。无论第三方库开源与否，编程语言是否与当前项目一致，我们最终的目的是在当前编程环境中调用库中的方法并得到结果或者借助库中的模块实现某种功能。这个过程会牵涉到很多东西，本篇文章将简要的介绍一下该过程的一些问题。 1.背景 多语言混合编程可以弥补某一种编程语言在性能表现或者是功能等方面的不足。虽然所有的高级语言都会最终转换成汇编指令或者最底层的机器指令，但是语言本身之间的千差万别很难一言以蔽之，这对不同语言之间相互通信造成很大的障碍。 工作中需要用python完成一项功能，但是所有现有的python库都不满足需求。最终找到了一个开源的C++库，编译得到动态库被python调用才完成工作需求。虽然整个过程耗时不多，但是期间碰到很多的问题，而且这些问题都很有思考价值。 除了这篇博文外，后续还将有一到两篇文章通过具体的实例讲解一下跨语言调用。 2.问题思考 在进行具体的介绍之前，先来思考一下调用外部库或者自己实现库所牵涉的一些一般性的问题。这样或许实际中操作使用时会理解的更加深刻，遇到问题也能够逐项的排查。 如果用C语言写的库调用了Linux的system call，纵使C本身是跨平台的，那么该库也不可能在Window上被使用，即便我们能拿到源码。这里有两个核心问题： 是否开源 是否跨平台 如果库的实现不依赖平台

Windows下DLL查找顺序 作者：Tocy 时间：2014-10-18 一、写作初衷 在Windows下单个DLL可能存在多个不同的版本，若不特别指定DLL的绝对路径或使用其他手段指定，在应用程序加载DLL时可能会查找到错误的版本，进而引出各种莫名其妙的问题。本文主要考虑以下两个方面： a. 参考MSDN，给出Windows下DLL查找顺序 b. 简单使用ProcessMonitor来验证DLL查找顺序 二、DLL查找顺序 （本部分多数内容是参考MSDN上的Dynamic-Link Library Search Order一文，链接如下 http://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx 。多数为翻译，有部分内容修改。本文仅关注桌面应用程序的查找顺序，对于Windows Store apps请参考MSDN原文。） 1. DLL查找路径基础 应用程序可以通过以下方式控制一个DLL的加载路径：使用全路径加载、使用DLL重定向、使用manifest文件。如果上述三种方式均未指定，系统查找DLL的顺序将按照本部分描述的顺序进行。 对于以下两种情况的DLL，系统将不会查找，而是直接加载： a. 对于已经加载到内存中的同名DLL，系统使用已经加载的DLL，并且忽略待加载DLL的路径。（注意对某个进程而言

DLL文件(Dynamic Linkable Library 即动态链接库文件)，是一种不能单独运行的文件，它允许程序共享执行特殊任务所必需的代码和其他资源 比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。在构造软件系统时，如果将所有模块的源代码都静态编译到整个应用程序 EXE 文件中，会产生一些问题：一个缺点是增加了应用程序的大小，它会占用更多的磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的 EXE 程序时，在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。 Windows 系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的 DLL 文件，并可对它们单独编译和测试。在运行时，只有当 EXE 程序确实要调用这些 DLL 模块的情况下，系统才会将它们装载到内存空间中。这种方式不仅减少了 EXE 文件的大小和对内存空间的需求，而且使这些 DLL 模块可以同时被多个应用程序使用。Windows 自己就将一些主要的系统功能以 DLL 模块的形式实现。 一般来说，DLL 是一种磁盘文件，以.dll、.DRV、.FON、.SYS 和许多以 .EXE

问题描述： 在delphi编程过程中，用delphi封装了一个动态链接库，将常用功能函数封装到dll,在delphi主工程文件中调用此dll,调用过程没有任何问题，但是在释放动态链接库handle的时候，即到FreeLibrary函数时，主工程与DLL之间有指针来往的时候，总是报access violation错误，将指针调用注释，即不报错，也就是内存管理的问题。 解决办法： delphi有一个共享内存管理单元ShareMem,在主工程与dll工程的工程文件中，在uses模块第一个引用位置，均加入对ShareMem单元的引用，问题随之解决。 这个问题很早之前就碰到过，可惜很久不用delphi，结果给忘了，为了下次不至于再到处找办法，做个笔记。 来源： https://www.cnblogs.com/martian6125/archive/2010/04/11/9631234.html

上网查资料， VS 创建 WIN32 DLL 一、为什么需要 dll 代码复用是提高软件开发 效率的重要途径。一般而言，只要某部分代码具有通用性，就可将它构造成相对独立的功能模块并在之后的项目中重复使用。比较常见的例子是各种应用程序框架， 如 ATL 、 MFC 等，它们都以源代码的形式发布。由于这种复用是“源码级别”的，源代码完全暴露给了程序员，因而称之为“白盒复用”。“白盒复用”的缺点 比较多，总结起来有 4 点。 暴露了源代码； 容易与程序员的“普通”代码发生命名冲突； 多份拷贝，造成存储浪费； 更新功能模块比较困难。 实际上，以上 4 点概括起来就是“暴露的源代码”造成“代码严重耦合”。为了弥补这些不足，就提出了“二进制级别”的代码复用。使用二进制级别的代码复用一定程度上隐藏了源代码，对于缓解代码耦合现象起到了一定的作用。这样的复用被称为“黑盒复用”。 在 Windows 操作系 统中有两种可执行文件，其后缀名分别为 .exe 和 .dll 。它们的区别在于， .exe 文件可被独立的装载于内存中运行； .dll 文件却不能，它只能被其它 进程调用。然而无论什么格式，它们都是二进制文件。上面说到的“二进制级别”的代码复用，可以使用 .dll 来实现。 与白盒复用相 比， .dll 很大程度上弥补了上述 4 大缺陷。 .dll 是二进制文件，因此隐藏了源代码；如果采用