.NET 依赖项副本导致较大的构建大小答案

【问题标题】：.NET dependency copy causing large build size.NET 依赖项副本导致较大的构建大小
【发布时间】：2015-03-06 00:23:14
【问题描述】：

我正在部署一个大型 dll，导致最终构建非常庞大。

所以我有引用 ProjectB 的 ProjectA，它引用第三方 DLL。此第三方 DLL 现在位于两个项目 bin 文件夹中，即使它仅由 ProjectB 直接引用。问题是这个第三方 dll 很大，并且由于它被复制到这么多 bin 文件夹中，导致最终构建很大。我真的只是在寻找这种情况下的最佳做法。

【问题讨论】：

请澄清您的问题。这是一个 web 项目还是一个 windows 项目？我真的不明白这个问题，因为通常当您部署应用程序时，除了它的 DLL 依赖项之外，还有一个可执行文件。换句话说，一个“项目”将编译成一个程序集，然后部署。 “项目”本身不会部署，只有程序集是。
这是几个 Web 项目，它们使用了几个使用这个大 dll 的库项目。我没有谈论部署，因为我的构建在开发人员机器和构建机器上都占用了大量空间。所以我们可能有一个数据访问类，它引用了这个用于数据库连接的大型 dll。然后，在 Web 项目中引用数据访问类。现在，大 dll 被复制到数据访问类和 web 项目 bin 文件夹中。
因为 ProjectA 引用了 ProjectB，这意味着您已将 ProjectB 复制到 ProjectA 的 bin 文件夹中，这意味着 ProjectB 需要大型 DLL 才能正确加载......因此它必须同时存在于两者中。 A 没有引用 C，但它确实引用了 B，B 引用了 C，否则 A 将无法加载 B 程序集。
@ErikFunkenbusch 这就是我的想法:(...希望有一些灵丹妙药，但似乎并非如此。
在构建项目 A 之后，您可能能够对项目 B 执行清理，但这意味着每次都必须完全重建 B。

标签： .net visual-studio dll

【解决方案1】：

由于您的第 3 方 DLL 很大并且在多个应用程序之间共享，因此可以将共享 DLL 放入 global assembly cache，而不是将其部署在每个应用程序中。

这只有在 DLL 是强命名的情况下才有效，但许多公司对他们的程序集进行强命名，所以您可以尝试一下。

这个想法是，您可以将这 1 个 DLL 拖放到 GAC 中，然后您可以继续在没有此文件的情况下部署应用程序的其余部分。只要将 DLL 放入正确的 GAC（框架版本和位数）并针对依赖项编译应用程序，.NET 框架就会在 GAC 中找到它，因此无需在每次部署时都包含它。

【讨论】：

他说他正在部署 bin，这会假设他不想将 GAC 用于任何事情。
@ErikFunkenbusch - 好的，你能想出另一种方法在项目之间共享一个巨大的 DLL 吗？
没错，我们以前在我们的应用服务器上安装了oracle客户端（dll是oracle运行时库），但我们不能再这样做了，所以我们必须bin deploy。不幸的是，我们有一些糟糕的设计，所以我们有大量直接引用预言机的项目，然后还有大量引用这些项目的项目。我正在尝试找出一种方法来减少将其复制到的 bin 数量，而不会破坏代码并且不必进行重大重写。不确定它是否可能，我想我会在这里问看看是否有我遗漏的东西。

【解决方案2】：

据我所知，主要原因是您将此引用设置为“复制本地”，导致它首先在项目之间重复。如果你将每个项目的引用正常添加，并且只将它设置为复制本地为 web 项目，那么复制的数量已经大大减少了。

【讨论】：