问题标签 [assembly-loading]

我在使用 Outlook 插件时遇到了非常奇怪的程序集参考问题和加载问题。以下是详细信息（说来话长：））：

我有一个旧的 Outlook 插件，使用 .Net 1.1 编写和构建。插件是使用其自己的应用程序域中的非托管 shim 加载的。使用 .Net 2.0 可以正常工作，即使用户机器上不存在 1.1。

该插件使用由 VS 2003 针对 Outlook 2000 创建的自定义 Outlook 互操作程序集，然后重建为强命名（就像我的插件一样）。

在插件项目中，我只引用了这个自定义互操作程序集，没有引用官方的 MS 互操作程序集。

当这个插件在 Outlook 2007 和 .Net 2.0 的环境中使用时，官方的 MS 互操作程序集安装在 GAC 中，出于某种原因，我看到插件加载并使用它们。

在 Connect 类的代码中，我有一个 using 指令：

这是我的自定义互操作程序集的命名空间。

在 Connect ctor 我有这些代码行（添加用于测试目的）：

这输出：

Outlook.Application 完整类型为：Outlook.ApplicationClass、Interop.Outlook、Version=9.0.0.0、Culture=neutral、PublicKeyToken=4cfbdc5349cf59d8

这正是我所期望的。

问题是，当调用 OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom) 时，我在日志中看到 MS 互操作（我有一个当前域的 AssemblyLoad 事件的挂钩）程序集也被加载：

输出：

程序集 Microsoft.Office.Interop.Outlook，Version=12.0.0.0，Culture=neutral，PublicKeyToken=71e9bce111e9429c 加载自：GAC

我的 OnConnection 方法是这样开始的：

这输出：

OnConnection 应用程序对象的完整类型是：Microsoft.Office.Interop.Outlook.ApplicationClass, Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

这真的很奇怪，你可以在下一行看到我可以成功地转换到 Outlook.Application 没有任何问题。

我已经检查过 Reflector，我的程序集不以任何方式引用 Microsoft 的互操作程序集。我的 Interop.Outlook.dll 也是如此。

那么，有人知道发生了什么吗？这些问题的答案是什么：

1. 为什么它会加载 Microsoft 程序集？

2. 如何在不同程序集中定义的不相关类/接口之间进行转换？

注意：我创建了一个新插件，非常简单，它什么都不做，只是加载。我可以重现这个问题，所以真的，有谁知道 CLR 如何决定加载什么互操作以及从哪里加载。除了在 GAC 中，还有其他地方（注册表？？？）在 COM 对象和它所需的互操作之间存在链接？

LoadFile我正在查看 msdn 文档，但对于使用程序集和LoadFrom加载程序集时的区别，我仍然有些困惑。有人可以提供一个例子或类比来更好地描述它。MSDN 文档让我更加困惑。此外，除了它仅在反射模式下加载程序集之外，ReflectionOnlyLoadFrom其他相同。LoadFrom

由于我的 .NET 经验不是最好的，这里有一些关于使用 LoadFile 的 MSDN 文档的问题：

LoadFile1)检查具有相同标识但位于不同路径的程序集是什么意思？身份是什么（例子）？

2) 它声明LoadFile不将文件加载到“LoadFrom Context”中，并且不使用加载路径解析依赖关系。这是什么意思，有人可以举个例子吗？

3）最后，它指出这LoadFile在这种有限的情况下很有用，因为 LoadFrom 无法加载具有相同身份但路径不同的程序集；它只会加载第一个这样的程序集，这又让我想到了同样的问题，程序集的身份是什么？

作为从 .net 1.1 迁移到 .net 3.5 的一部分，我们不得不更改一些供应商 DLL。

其中之一是在我们使用它的 4 个位置中只有 1 个位置给我们带来麻烦：

问题点是一个 Windows 窗体项目，它使用反射来动态加载一些运行长时间运行的进程的 DLL。这些长期运行的进程之一是依赖于我们的供应商 DLL 之一的代理

在我们第一次输入引用库的函数时，我们得到了缺少的程序集异常。我已经检查了一些愚蠢的事情，例如我们是否忘记将引用从旧版本移动到新版本，但事实并非如此。我还检查了项目的 bin 目录，程序集就在那里。

有没有人遇到过 .net 2.0 运行时拒绝加载这样的程序集的情况？如果是这样，我们如何解决这个问题。

附加信息：

在这种情况下，特定的供应商是 dtSearch，这是引发错误的边界：

该库在 SetIndexOptions 中被引用。BuildIndex()被输入，但在调用 SetIndexOptions 时发生异常。该函数从未实际输入。

我正在移植一个 Java 应用程序，其中在运行时从内存（字节数组）加载和“执行”类。我试图在 C# 中实现相同的目标，但是System.IO.FileNotFoundException在尝试从字节数组加载程序集（使用该AppDomain.Load方法）时遇到问题（异常）。

有没有办法加载它们而不需要将此字节数组持久化到文件系统中？

简化这个想法，我们希望能够动态地执行和更改（更新）代码。我们使用单独的应用程序域来“加载/卸载”程序集。

我正在尝试确定 MEF 是否是我们的应用程序框架应该采用的正确方向。从我对 MEF 的阅读来看，我们的框架似乎并不“完全”适合，但我会看看是否有专家可以指导我。

我们的框架允许我们将一个核心网站和依赖程序集部署到一个地方（并将修复或功能传播给所有客户），然后我们将客户网站“合并”到核心网站并在需要的地方扩展它。

现在在 IIS 中，每个客户端站点都是在其自己的 AppDomain 中运行的自己的应用程序。但是，每个应用程序都有指向“核心网站”的相同物理路径。

所以我们的文件结构是...

• /核心站点
  • /bin（包含核心站点和依赖 dll）
  • /[核心站点文件夹]（例如模型、视图、控制器、内容等）
  • /客户
    • /_Assemblies（包含所有客户端程序集 - 100 个客户端）
    • /客户1
      • /[客户端站点文件夹]（例如模型、视图、控制器等）
    • /客户2
      • /[客户端站点文件夹]（例如模型、视图、控制器等）
    • /客户N

所以你可能已经猜到了，程序集加载是我们的问题。出于几个原因，我们不想将所有客户端程序集放入根 /bin 文件夹中。首先，我们不希望每个客户端站点都加载所有其他客户端程序集。其次，我们不希望每个站点的 AppDomain 都因为 /bin 文件夹中更新了另一个客户端的程序集而被回收。

为了在 asp.net 1.1 中进行这项工作，我们遵循http://www.hanselman.com/blog/MovingTheCodeBehindAssembliesDLLsToADifferentFolderThanBINWithASPNET11.aspx并在 web.config 中添加了 <probing privatePath="bin;Clients/_Assemblies"/> 元素在客户端站点的每个视图中使用 <%@ Assembly Name="ClientN" %> 指令。我们必须克服的唯一其他问题是更新客户端程序集，但 asp.net 1.1 会将程序集锁定在 /Clients/_Assemblies 目录中。我们简单地添加了：

和中提琴，一切似乎都像魅力一样运作。不幸的是，在 asp.net 4.0 中，AppDomain.CurrentDomain.SetShadowCopyPath() 已被弃用。因此，我们一直在尝试从字节数组中自己加载程序集，尝试使用 AssemblyResolve 事件，在 [assembly: PreApplicationStartMethod( typeof( MvcApplication ), "PreApplicationStart" )] 中搞砸，尝试使用 System. Compilation.BuildManager.AddReferencedAssembly 无济于事。

我们要么得到： - 没有加载程序集 - 加载了太多程序集，或者 - 程序集被加载但是当视图正在呈现并遇到命名空间应该从 <%@ Assembly Name="ClientN" 定位的 <Import/> 指令%> 只是失败了。

因此，我要求使用任何机制和/或关于 MEF 是否可行的建议提出任何建议。我的 1000 英尺观点是，MEF 更适合 1 个应用程序（和/或网站），其中插入了多个组件。我犹豫是否开始进行主要的代码重构（似乎），因为在我们的情况下，每个应用程序/应用程序域一次只有一个组件插入其中。它似乎也比我们需要它做的更多（只需加载程序集并让 asp.net 识别它......然后我们所有的代码都会工作）。

任何意见是极大的赞赏。

使用它们的含义和建议的场景是什么？

我正在编写一个新的基于插件的应用程序。这会在它们自己的应用程序域中加载程序集，并通过 Application.Run(pluginForm) 在每个程序域中显示指定的主表单。在应用程序域中调用 Application.Run(pluginForm) 之前，我将加载器应用程序中的主窗体设置为每个 pluginForm 的父窗体。因此，当 pluginForm 显示时，它总是显示在加载器应用程序的 mainForm 前面。

我的问题是，当用户第一次点击 pluginForm（子表单）时，它失去了焦点，而 mainForm（加载器应用程序的表单）获得了焦点。（但是 pluginForm 保持在前面）因此用户最终必须单击两次才能使 pluginForm 第一次聚焦。

这很烦人。我怎样才能解决这个问题？

1) .NET Assembly MyAssembly.dll实现了一个 Singleton 类MyClass

2) .NET APP 引用了MyAssembly.dll并使用MyClass

3) .NET ActiveX MyActiveX.dll实现了一个 COM Visible 类，该类又引用MyAssembly.dll中的MyClass

我的问题是：如果应用程序和 ActiveX 同时运行（网页中的 ActiveX），我是否加载了一个或两个MyAssembly.dll实例？我需要它成为单例工作的一个实例。

谢谢

在插件系统中，我实例化对象并根据一些传入的请求调用这些对象的方法，这些请求具有一些标识符（只是一个字符串）。在配置的帮助下，此标识符确定要加载哪个程序集、要实例化此程序集中的哪个类以及调用哪个方法。这些程序集被加载到一个单独的 AppDomain 中。这发生在这样创建的代理类中：

在 SecondDomainProxy 类中，我加载与identifier上述相关的程序集：

问题：一旦程序集被加载，保持对这个 Assembly 对象的引用是否有意义？例如使用字典...

...并将上面的代码更改为：

我知道程序集是在第一次调用 Assembly.LoadFrom 之后加载的，直到 AppDomain 被卸载。（在我的例子中，第二个 AppDomain 的生命周期与主应用程序一样长。）那么这是否意味着对 Assembly.LoadFrom 的第二次调用很便宜，与字典查找一样便宜或几乎一样便宜？还是不调用 assembly.LoadFrom 而是使用保存的引用是否有缺点？

（我的感觉是，除非我有我没有的高性能要求（大约每 15 秒一个请求），否则这并不重要。但我可能是错的。）

感谢您提前反馈！

编辑：

Assembly是一个“普通”的 .NET 类。如果我没有对此类实例的任何引用，我认为它会被垃圾收集。但是程序集本身仍然处于加载状态。所以Assembly.LoadFrom至少需要创建一个Assembly 类的新实例，尽管在第二次这个实例创建可能基于已经加载的程序集。

我想补充一个问题：为给定程序集创建程序集对象是否需要大量反射，因此无论是否加载程序集总是很昂贵？

我正在尝试找到一种在运行时编译程序集并加载它们的方法。基本意图是将它们存储在不在磁盘上的数据库中。所以我写了一些代码，但看到了一个有趣的情况。这是我的代码：

代码运行完美，删除行被注释掉，如果我取消注释，应用程序域加载程序集，AssemblyLoadEvent()方法运行，我在控制台上看到数字 9，但是当方法结束时apd.Load()抛出错误：“无法加载文件或程序集。” 这是完全合理的。

AssemblyLoadEvent()问题是：如果没有光盘上的程序集文件，方法如何运行？

如果该方法在原始二进制数据的帮助下以某种方式运行，那么 appdomain 是否有任何Load()方法成功完成该方法？