5

这是我的示例场景。我有一个控制台应用程序和一个类库 dll（称为 libraryA）。LibraryA dll 引用了 Oracle.DataAccess.dll 版本 4.112.2.0。Oracle DLL 在 GAC 中。LibraryA 中对 Oracle DLL 的引用是“Copy Local = false”。到目前为止，一切都很好。如果您构建 libraryA dll，则 Oracle.DataAccess.dll 不会显示在其输出目录中。好的。现在我在我的控制台应用程序中引用 libraryA dll。对 libraryA dll 的引用是“copy local = true”。现在，当我构建控制台应用程序时，Oracle.DataAcess.dll确实显示在控制台应用程序的输出目录中。但是，似乎唯一以这种方式运行的 DLL 是 Oracle dll。这是LibraryA的完整代码

public void Foo() {            
   Oracle.DataAccess.Client.OracleConnection c = new Oracle.DataAccess.Client.OracleConnection();
   WebMatrix.WebData.OAuthAccountData x = new WebMatrix.WebData.OAuthAccountData("asd", "asd");            
   DevExpress.Web.ASPxCallback.ASPxCallback cvv = new DevExpress.Web.ASPxCallback.ASPxCallback();
}

WebMatrix 和 DevExpress 也像 Oracle DLL 一样在 GAC 中。但是，这些 DLL 都不会输出到输出目录，只有 Oracle dll。为什么？这里发生了什么事？

就此而言，您可以创建另一个类库，将其命名为 libraryB，不要将 libraryB 放入 GAC，从 LibraryA 引用 LibraryB 并设置 copy local = false。即使您这样做，libraryB 也不会复制到控制台应用程序的输出目录中。当然，在这种情况下，程序会因为找不到库 B 而崩溃，但至少 Visual Studio 尊重复制本地标志 = false。这个愚蠢的 Oracle DLL 有什么不同？

哦，还有一件事很有趣。如果在我的控制台应用程序中，我明确添加了对 Oracle.DataAccess.dll 的引用，并说 copy local = false，那么它不会显示在输出目录中。在输出目录中没有显示 DLL似乎有点搞笑，我必须实际引用它:)

编辑：

另一个线索。Oracle，为了折磨开发者，没有为 AnyCPU 构建一个 DLL。他们有一个 x86 和一个 x64 版本。就我而言，我引用的是 x86 版本并为 AnyCPU 构建。但是，如果我为x86构建（以匹配 oracle dll），那么 Oracle DLL不是复制到输出目录。在 AnyCPU 中构建时，MSBUILD 说：“警告 MSB3270：正在构建的项目“MSIL”的处理器架构与参考“Oracle.DataAccess，版本=4.112.2.0，文化=中性”的处理器架构不匹配， PublicKeyToken=89b483f429c47342, processorArchitecture=x86", "x86"。这种不匹配可能会导致运行时失败。请考虑通过配置管理器更改项目的目标处理器架构，以便在您的项目和参考之间对齐处理器架构，或者采取依赖于具有与您项目的目标处理器架构相匹配的处理器架构的参考。” 所以，看起来 Msbuild 最终决定，好吧，你有一个不匹配，保证你的应用程序会爆炸。:)

4

2 回答 2

5

通过不引用它，你让它使用隐式规则。好吧，这里的隐含默认值是“将其复制到本地”，因为大多数dll 不在 GAC 中。IDE 有一个疯狂的概念，即默认为“让它工作”，这意味着“假设它不会在 GAC 中”。

如果你想使用明确的规则，那么是的：你需要告诉它你想要什么。你这样做的方法是添加一个参考，然后设置你想要的选项。

于 2013-02-17T17:26:15.287 回答
0

在对我正在处理的解决方案中似乎存在相同问题进行大量调查后，我们发现此问题似乎是由 .NET 4.5 版本引入的新检查引起的，如此处所述：在构建时，现在正在检查引用以确保它们的处理器类型与项目的处理器类型匹配。

虽然之前我们在构建日志中没有看到任何此类错误，但在受影响的机器上，我们现在看到一条消息，表明项目正在为 MSIL 构建并且 DLL 是为 x86 构建的 - 而不是为所有 CPU 构建可用的一个 DLL，第三方创建者为 x86 和 x64 提供了两个单独的 DLL，它们都在我们的 GAC 中。在引入此检查之前，系统将使用 GAC 中的 DLL 并选择适当的版本，但似乎在安装 .NET 4.5 后，构建过程确定 GAC 中的任何一个版本都不可接受，因此它正在引入本地副本。

我们无法确定禁用此行为的任何方法，因此我们的解决方案必须是添加一个构建后事件以删除本地副本，或者（如问题中所述）添加引用将问题 DLL 指向所有引用我们“库 A”的项目，然后将这些引用设置为“copy local = false”，这似乎也阻止了将非工作本地版本复制到输出中。

于 2015-01-22T14:21:45.480 回答