此问题之前已在SO上提出,例如here和here。方案是,人们希望在其应用程序中使用COM组件,而无需在计算机上注册COM组件。这是通过向客户端添加两个清单文件和向服务器添加一个清单文件来实现的,并且操作系统的并排功能负责其余部分。现在,当所有Dll都在同一个文件夹中时,这可以正常工作。
在我的特定场景中,我正在尝试使用传统的.net 2.0 dll访问4.0 dll。我们不想改变2.0 dll,并且通过上面的方法,我能够实现这一点。但是,如果4.0 dll位于可执行文件的子文件夹中(2.0 dll)。当并排执行开始时,找不到4.0 dll。我正在调用win32 API并创建一个新的ActivationContext传入清单文件。我使用了ProcMon,看到dll正在可执行文件目录中查找,而不是在清单中为查找指定的路径中查找。由于上面的链接也证明了.net似乎只知道清单中的ClrClass而忽略了为私有程序集查找提供的AssemblyLocation,这是不幸的!
无论如何,上述链接中的解决方法是GAC和AssemblyResolve。如果可能的话我不想通过GAC并且AssemblyResolve对我不起作用,因为我必须在2.0 dll中订阅它而无法加载4.0 dll。
是否有任何类型的黑客让应用程序认为它暂时位于其他地方以便找到dll?
我也知道使用服务(web,windows)来启用调用4.0应用程序的2.0应用程序。除上述三种情况外,任何其他可能性都会受到赞赏。
答案 0 :(得分:1)
您应该能够使用app.config
中的<probing>
元素在查找程序集时让CLR查看子文件夹。因此,如果您的4.0 DLL位于子文件夹ComDll
中,您的app.config将如下所示:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="ComDll"/>
</assemblyBinding>
</runtime>
</configuration>
私人路径必须是EXE的子文件夹,这应该适用于您的情况。