【发布时间】：2013-08-01 00:54:21
【问题描述】：
我已将托管接口添加到本地 C++ 应用程序，该应用程序实例化 CLR、创建自定义 appDomainManager 并提供将托管程序集加载到本地进程的调用。在我的本机 C++ LoadDLL() 函数中，我希望能够通过调用 LoadLibrary(dllPath) 来测试 .net 与 C++ 的传入 dll，我认为这将返回托管程序集的失败 (NULL)，但我发现它而是返回一个句柄（这在非托管进程中当前没有运行 CLR）。这是对托管程序集的非托管 LoadLibrary() 调用的正常行为吗？
我不确定我是否理解 LoadLibrary 如何找到合适的入口点以在托管程序集中进行测试。我知道（一种可能的）解决问题的方法，以及我计划实现的方法，就是使用 CLR 实例访问 .net 反射 API 并检查 DLL 是否首先在那里管理......但我'对 LoadLibrary() 没有返回失败的事实感到困惑，我想了解我在这里缺少什么。行为是否未定义，是否应该始终返回句柄，还是取决于托管程序集的配置？任何指向参考的链接表示赞赏。
编辑：
问题已在 cmets 中回答，结束。
【问题讨论】：
-
.NET 程序集在 Windows 中看起来就像一个普通的 DLL。所以 LoadLibrary 工作正常。接下来您通常会执行此操作，调用 GetProcAddress() 以在 DLL 中找到一个不起作用的入口点。纯托管的 .NET 程序集没有。所以不要使用LoadLibrary，这是没有意义的。一大堆sample code向你展示如何使用_AppDomain接口。
-
感谢您的回复。我已经实现并工作了 _AppDomain 接口，我只是好奇为什么 LoadLibrary 没有在 .net 程序集上失败并想验证正常行为。调用在一个实际上无法执行任何有用操作的程序集上成功，这似乎不是很奇怪吗？这只是一个时髦的逻辑漏洞，还是将托管程序集加载到我不知道的非托管进程中还有其他用途？
-
不，这并不奇怪。 .NET 程序集也可以包含非托管代码，因此调用 LoadLibrary + GetProcAddress 对于这样的程序集是完全合理的。当 DLL 没有导出函数时，Windows 中没有内置的特殊功能禁止调用 LoadLibrary。例如，仅包含资源的 DLL 是完全有效的。
-
太棒了，谢谢你的信息
-
@HansPassant C++ 托管的 dll 怎么样。它可以在 C++ 应用程序中与 LoadLIbrary 一起使用吗？
标签： c++ .net unmanaged managed loadlibrary