如何在不使用 GAC 的情况下使 C++/CLI DLL 解决对托管程序集 (DLL) 的依赖？

Question

我们目前将 ODBC 驱动程序构建为 4 个 DLL：

1. 实现 ODBC (C) API 的 DLL，主要用 C++ 实现， 使用 C++/CLI 编写的一些“胶水”代码，用于与 #2、#3 和 #4 交互

2. 包含托管程序集（用 C# 编写）的 DLL，该程序集定义了用于 #1 和 #4 相互通信的“基本”接口。

3. 另一个 DLL 包含一个托管程序集，该程序集依赖于 #2，并为 #2 中的类定义了一些扩展
4. 另一个包含托管程序集的 DLL，其中包含“业务 驱动程序的逻辑'，取决于#2 & #3

为了部署驱动程序，我们将 DSN 配置为指向 #1，并将 #2、#3 和 #4 放入 GAC。

我们有一位客户想要完全避开 GAC。我知道将 #2、#3 和 #4 与加载 #1 'works'的应用程序放在同一目录中，但这不是一个好的解决方案，因为许多不同的应用程序可能会使用该驱动程序。

我们如何设置它以便在没有 GAC 的情况下解决依赖关系？我尝试创建清单文件（基于https://docs.microsoft.com/en-us/windows/win32/sbscs/assembly-manifests），但这似乎不起作用（EEFileLoadException 异常被抛出，因为它找不到托管程序集，当我从GAC）。我将清单文件和所有 .DLL 文件放在同一个目录中。

通过谷歌搜索，我找不到任何好的文档/示例。

Answer 1

我不确定我是否完全理解你的问题，但我会尽力回答：

在尝试解决这个问题时，我们应该记住以下几点：

1. Fusion 不会启动（因此依赖解析），直到您位于未解析类型的第一次出现所在的堆栈帧中。
2. 我们可以假设 CLR 已经加载到宿主进程中，并且我们至少有一个 Appdomain。 （否则，您必须考虑这两种情况 - 特别是被默认情况下不加载 CLR 的进程消耗。在这种情况下您想做什么？自己加载 CLR？隐式？显式？如果是这样，您如何配置您的 Appdomain？您的 App Root 在哪里？您的探测路径是什么？)

鉴于这两点，您可以订阅AppDomain.AssemblyResolve Event。但是您应该以这种方式重构您的代码，因此 fusion 在您设法订阅之前不会尝试解析您的程序集。在处理程序中，仅处理正在解析 YOUR 程序集的事件，并从您想要的任何位置加载它们 - 例如，从本地库所在的同一路径。

补充阅读：

• CLRCreateInstance Function
• How to load CLR in to a process, create an AppDomain and load an assembly

Answer 2

根据 cmets 更新...

我在此处的 Microsoft 文档中发现了一个有趣的点：docs.microsoft.com/en-us/windows/win32/dlls/... --“如果 DLL 具有依赖关系，系统会搜索依赖的 DLL，就好像它们是只加载了它们的模块名称。即使第一个 DLL 是通过指定完整路径加载的，也是如此。这意味着如果这些 dll 由任何其他进程加载，则将使用内存中具有该名称的版本。

基本上微软的文档所说的是：

除非计算机上存在与#2-#4 模块名称相同的其他dll，否则您无需担心。无论您是否将这些 dll 放入 GAC。 #1 将由应用程序使用您指定的任何路径加载，#2-#4 将仅按模块名称加载。

您唯一的问题是，如果您的模块 #2-#4 没有良好的独特名称，并且可能存在其他具有相同名称和不同定义的模块。这是因为它们将仅按名称加载。

至于执行顺序...#1 是您的入口点，如果它依赖于 #2，它将在任何执行之前加载，依此类推。除非你对你的构建指令做了一些明确的事情，但你现在的实现也会遇到这种情况。