问题标签 [assemblies]

如果您创建一个使用来自其他程序集的东西的类库，是否可以将这些其他程序集作为某种资源嵌入到类库中？

即不是让MyAssembly.dll，SomeAssembly1.dll和SomeAssembly2.dll坐在文件系统上，其他两个文件被捆绑到MyAssembly.dll中并且可以在其代码中使用。

我也有点困惑为什么 .NET 程序集是.dll文件。这种格式在.NET 之前不存在吗？是否所有 .NET 程序集 DLL，但并非所有 DLL 都是 .NET 程序集？为什么他们使用相同的文件格式和/或文件扩展名？

如果 A 引用程序集 B 1.1 和 C，而 C 引用 B 1.2，如何避免程序集冲突？

我很好地假设 C 的引用会被封装掉并且不会导致任何问题，但似乎所有的 dll 都被复制到了 bin 中，这就是问题发生的地方。

我了解解决此问题的两种方法是使用 GAC 或程序集绑定？GAC 对我来说似乎不是最好的方法，因为我不喜欢假设 dll 会在那里，我更喜欢在我的解决方案中从 lib 目录中引用 dll。

由于程序集绑定对我来说似乎不健壮，如果程序集的一个版本具有另一个版本没有的功能怎么办，这不会产生问题吗？

在我的情况下，因为我使用的是第 3 方 dll，它使用的是旧版本的 nHibernate，而不是我自己使用的。

我正在编写一个工具来报告有关在我的客户系统中跨环境和区域部署的 .NET 应用程序的信息。

我想读取这些程序集中的程序集属性值。

这可以使用 来实现Assembly.ReflectionOnlyLoad，但是即使这种方法也会使程序集保持加载。这里的问题是我不能从不同的路径加载两个同名的程序集，所以自然不能比较部署在不同系统中的同一个应用程序。

在这一点上，我假设解决方案将涉及使用临时AppDomains。

有人可以详细说明如何将一个程序集加载到另一个程序集中AppDomain，从中读取属性然后卸载AppDomain吗？

这需要适用于文件系统上的程序集以及 URL 地址上的程序集。

我创建了一个 .NET DLL，它使一些方法 COM 可见。

一种方法是有问题的。它看起来像这样：

当我尝试调用该方法时，VB6 给出了一个编译错误：

标记为受限的函数或接口，或函数使用 Visual Basic 不支持的自动化类型。

我读到数组参数必须通过引用传递，所以我更改了签名中的第一个参数：

VB6 仍然给出相同的编译错误。

如何更改签名以与 VB6 兼容？

我写了一个在程序集 dll 中的UserControl 后代。

如何将控件放在表单上？

我在解决方案资源管理器的引用节点下添加了对程序集的引用，但我的工具箱中没有出现新控件。

如何使控件出现在工具箱中，以便我可以将其放在表单上？

更新 1：

我尝试在 Visual Studio 选项中构建程序集：

工具-->选项... --> Windows 窗体设计器--> AutoToolboxPopulate = true

在新解决方案的工具箱中时，该控件未出现。

注意：我不知何故错误地写了“……那不在程序集 dll 中……”。我不知道我是怎么写出来的，特别是在程序集 dll 中。当它们在同一个项目中时，控件神奇地出现了，但现在不是因为它是不同的项目/解决方案。

更新 2：答案

1. 右键单击工具箱
2. 选择选择项目...
3. .NET Framework 组件选项卡
4. 选择浏览...

5. 浏览到包含控件的程序集 dll文件并选择打开

   注意：程序集中的控件将以静默方式添加到 .NET Framework 组件列表中。

6. 检查您希望出现在工具箱中的每个控件
7. 选择确定

对于允许除完全受信任的调用方以外的任何内容的 .NET 程序集，必须使用AllowPartiallyTrustedCallers对程序集进行签名和属性化。

但是即使这样，CLR 仍然（幸运的是）检查代码权限以确保部分受信任的调用者可以执行所需的代码。

所以我的问题是，为什么不对所有程序集假定 AllowPartiallyTrustedCallers 属性？为什么不让那些真正不希望部分受信任的呼叫者必须使用诸如 DenyPartiallyTrustedCallers 之类的属性的相反呢？

不久前，我在 Stack Overflow、 Assembly Names and Versions上问了以下问题。

现在我意识到我不能用强名称签署我的程序集，因为第 3 方依赖项之一不是强名称程序集，因此我的程序集不可签名。

我试图简单地将程序集文件名 MyAssembly.dll 更改为 MyAssembly.v.1.1.dll 但是当我这样做并引用重命名的程序集时 - 它不会像其他引用一样被复制。似乎是因为文件名和程序集的 Identity 属性不匹配。

我有项目 A 和 B，它们是项目 C 的依赖项。项目 A 需要引用 MyAssembly.dll v.1.0，项目 B 需要引用 MyAssembly.dll v.2.0，因此两者都需要能够位于项目 C 的 bin/发布文件夹。

有什么可做的？我怎样才能解决这个问题？

我有一个类型的引用，我想检索它所在的程序集的版本号。

做这个的最好方式是什么？

我想知道公共方法及其返回值的最佳实践是什么。从引用的程序集中返回类型是否可以，或者我应该确保所有参数和返回值都来自同一个程序集？

我问的原因是我正在将程序集与 ILMerge 合并，我想内部化除主程序集之外的所有程序集，但如果我在主程序集中有公共方法，这似乎是不可能的参数或返回内部程序集中的类型的值。

为了澄清我在说什么，我从 CommonUtils 项目中引用 Oracle.DataAccess，并使用 DbUtils 来创建在 Oracle.DataAccess 中定义的 OracleParameter 类型，这是我想要内部化但不能的程序集。

任何人都可以为我澄清这一点吗？

我想知道在创建要包含在与依赖项相关的其他项目中的库版本时的启发式方法是什么，以及是否应该包含它们。

我的问题如下：

我有一个 CommonUtilities 库，顾名思义，它提供了一组可以在多个地方使用的实用程序。CommonUtilities 的依赖项包括 log4net.dll（日志框架）和 Oracle.DataAccess.dll（数据库驱动程序）。

我有另一个名为 MyProject 的项目，我想在其中包含 CommonUtilities。MyProject 还依赖于 Oracle.DataAccess。

如果我使用 ILMerge 并将 CommonUtilities 合并到单个程序集 CommonUtilities.dll 中并从 MyProject 中引用它，那么一切都会编译，但我确信我应该从 MyProject 显式引用 Oracle.DataAccess，因为它是一个依赖项，而不是使用合并到 CU 中的程序集。添加对 Oracle.DataAccess 的引用也会导致使用语句不明确，因为引用了两个 Oracle.DataAccess 程序集。

在我的情况下使用 ILMerge /Internalize 会导致编译错误，因为来自内部化的 Oracle.DataAccess 程序集的类型正在从 CommonUtilities 返回，并且它们被标记为内部 MyProject 无法识别返回的类型。

完成这项工作的唯一方法就是不将此特定程序集 (Oracle.DataAccess) 合并到 CommonUtilities 中，而仅从 MyProject 中引用它。这反过来又产生了一个新问题：我应该引用哪个 Oracle.DataAccess.dll - 是否使用 CommonUtils 分发的依赖项？

还有其他方法可以解决这一切吗？