知识大全 C++/CLI中有效使用非托管并列缓存

Posted 2022-07-17 文件

篇首语：什么是知识?它不是别的，是记录下来的经验。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 C++/CLI中有效使用非托管并列缓存相关的知识，希望对你有一定的参考价值。

C++/CLI中有效使用非托管并列缓存 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

Visual Studio安装程序会把Visual Studio的共享库放在一个称为并列缓存（side by side cache）的地方那怎样才能有效地利用它呢？　　在文章开头先看一个示例在命令行中创建一个C++源文件输入例中的代码（虽然此处使用的是C++/CLI语法但不管你是用C++/CLI 托管C++ 或本地C++ 都不影响要讲解的主题）　　例 lib cpp using namespace System;public ref class Test　public:　　void CallMe()　　　　　　Console::WriteLine( called me );　　;　　将其编译为一个托管库程序集 cl /clr /LD lib cpp　　在此要多留意我们是使用了混合模式（/clr）来编译此代码当然了如果适当修改也能以旧式托管C++语法（/clr:oldsyntax）来编译　　下一步创建一个调用此库的C#程序（例）当然也可以使用Visual Basic NET 不过C#更好一点再与库一起编译　　例 using System;class App　static void Main()　　　Test test = new Test();　　test CallMe();　csc app cs /r:lib dll　　运行此程序会抛出一个异常 Unhandled Exception: System IO FileNotFoundException: The specified module could not be found (Exception from HRESULT: x E)at App Main()　　怎么会这样呢？打开程序所在的目录库也在那啊 HRESULT的高位字为 x 其代表FACILITY_WIN 也就是说这是一个Win 错误低位字以十进制表示为在winerror h中列明其代表ERROR_MOD_NOT_FOUND 如果LoadLibrary不能查找到某个模块才会返回这个错误结果因此现在非常清楚了这个错误表示不能查找到一个非托管的DLL 　　为找出库所使用的模块列表可在ILDASM中加载它并查看MANIFEST 如果库是通过平台调用加载DLL的那这些DLL会作为 module条目列出然而对这个库来说你将会发现它只用到了托管程序集mscorlib与Microsoft VisualC 两者都在 NET全局程序集缓存（GAC）中另有一种可能性在程序集中还存在着非托管代码由它调用了非托管库（例如那些使用托管C++ It Just Works的代码）　　为调查清楚从ILDASM的View菜单中选项Headers 这将会列出库中的PE文件头向下滚动直至找到导入表（IAT）会得到一份所有从非托管库引入的方法列表因为库是以混合模式编译的因此库用到了C运行时库（CRT）从导入表中也确认了这点它列出了msvcr dll及msvcm dll 前者是CRT的DLL多线程版本后者是一个包含了一些CRT托管版本的混合模式库这下非常清楚了错误产生的原因是Windows找不到这两个库或其一　　最后查看%systemroot%\\system 目录下是否有这些库但它们不会在那的此时你可能会指责Visual Studio安装程序没有把最新版本的CRT安装在自己的电脑上但实际上安装程序已经安装了这些CRT库只是不在你原先期待的地方　　 并列缓存　　Visual Studio安装程序会把Visual Studio的共享库放在一个称为并列缓存（side by side cache）的地方目录位于%systemroot%\\WinSxS 且只有SYSTEM及Administrators组成员有写访问权限其他用户只有读取和运行权限并列缓存中包含了程序集不是托管程序集而是非托管的等价物　　在WinSxS目录下每个程序集都会有一个目录另外还有两个目录分别是Manifests和Policies 其中包含了版本的相关信息以下两个目录与CRT有关 x _Microsoft VC CRT_ fc b b a e e b_ _x ww_ de acdx _Microsoft VC DebugCRT_ fc b b a e e b_ _x ww_f eb c

　　显而易见一个是发布版（Release Build）而另一个是调试版（Debug Build）但重点是版本号与一个公有密钥权标也是目录名的一部分如果你查看前一个目录的内容可看到有msvcm dll msvcp dll 及msvcr dll 它们是被称为 Microsoft VC CRT 非托管程序集版本的内容一个非托管程序集可包含一个或多个文件而这些文件也可为包含本地代码或对象的DLL 一个非托管程序集通常被作为一个单独的单元部署且其中的所有文件由一个被称为清单（manifest）的XML文件来描述　　清单文件存储在Manifest目录中且与程序集同名但是后缀名为 manifest 这个文件列出了程序集中的所有文件此外还有一个文件的文件名也与程序集同名但是后缀名为 cat 这是一个已签名的安全编目文件其包含了程序集中文件的hash值正是因为它已签名所以可以防止被篡改且Windows也能利用这些hash值来检查程序集的任一部分是否在部署后已被篡改

　　 using namespace System;public ref class Test　public:　　void CallMe()　　　　　　Console::WriteLine( called me );　　;

　　将其编译为一个托管库程序集

　　 cl /clr /LD lib cpp

　　在此要多留意我们是使用了混合模式（/clr）来编译此代码当然了如果适当修改也能以旧式托管C++语法（/clr:oldsyntax）来编译　　下一步创建一个调用此库的C#程序（例）当然也可以使用Visual Basic NET 不过C#更好一点再与库一起编译　　例

　　 using System;class App　static void Main()　　　Test test = new Test();　　test CallMe();　csc app cs /r:lib dll

　　运行此程序会抛出一个异常

　　 Unhandled Exception: System IO FileNotFoundException: The specified module could not be found (Exception from HRESULT: x E)at App Main()

　　怎么会这样呢？打开程序所在的目录库也在那啊 HRESULT的高位字为 x 其代表FACILITY_WIN 也就是说这是一个Win 错误低位字以十进制表示为在winerror h中列明其代表ERROR_MOD_NOT_FOUND 如果LoadLibrary不能查找到某个模块才会返回这个错误结果因此现在非常清楚了这个错误表示不能查找到一个非托管的DLL 　　为找出库所使用的模块列表可在ILDASM中加载它并查看MANIFEST 如果库是通过平台调用加载DLL的那这些DLL会作为 module条目列出然而对这个库来说你将会发现它只用到了托管程序集mscorlib与Microsoft VisualC 两者都在 NET全局程序集缓存（GAC）中另有一种可能性在程序集中还存在着非托管代码由它调用了非托管库（例如那些使用托管C++ It Just Works的代码）　　为调查清楚从ILDASM的View菜单中选项Headers 这将会列出库中的PE文件头向下滚动直至找到导入表（IAT）会得到一份所有从非托管库引入的方法列表因为库是以混合模式编译的因此库用到了C运行时库（CRT）从导入表中也确认了这点它列出了msvcr dll及msvcm dll 前者是CRT的DLL多线程版本后者是一个包含了一些CRT托管版本的混合模式库这下非常清楚了错误产生的原因是Windows找不到这两个库或其一　　最后查看%systemroot%\\system 目录下是否有这些库但它们不会在那的此时你可能会指责Visual Studio安装程序没有把最新版本的CRT安装在自己的电脑上但实际上安装程序已经安装了这些CRT库只是不在你原先期待的地方　　并列缓存　　Visual Studio安装程序会把Visual Studio的共享库放在一个称为并列缓存（side by side cache）的地方目录位于%systemroot%\\WinSxS 且只有SYSTEM及Administrators组成员有写访问权限其他用户只有读取和运行权限并列缓存中包含了程序集不是托管程序集而是非托管的等价物　　在WinSxS目录下每个程序集都会有一个目录另外还有两个目录分别是Manifests和Policies 其中包含了版本的相关信息以下两个目录与CRT有关

　　 x _Microsoft VC CRT_ fc b b a e e b_ _x ww_ de acdx _Microsoft VC DebugCRT_ fc b b a e e b_ _x ww_f eb c

cha138/Article/program/net/201311/12469