Visual Studio 2010 程序集参考问题答案

【问题标题】：Visual Studio 2010 Assembly Reference IssueVisual Studio 2010 程序集参考问题
【发布时间】：2011-12-25 14:17:48
【问题描述】：

我正在使用 Visual Studio 2010 和 C# 来构建 WinForms 应用程序和类库。我有一些用于所有产品的通用库，还有一些用于我的应用程序的产品特定库。我的所有程序集都不是 GAC 的。所有项目都将其输出从各自的 bin\Debug 文件夹复制到一个公共 Repository 文件夹，并且所有程序集引用都指向该 Repository 文件夹。

例如，Common.DAL.dll、Common.BLL.dll、Product.DAL.dll、Product.BLL 和 Product.exe

程序集之间的引用通常是这样的：

Product.exe 包含对 Product.BLL 的引用
Product.BLL 包括对 Common.BLL 和 Product.DAL 的引用
Product.DAL 包含对 Common.DAL 的引用
Common.BLL 包括对 Common.DAL 的引用

当所有这些都包含在同一个解决方案中时，构建依赖项是这样的：

Common.BLL 依赖于 Common.DAL
Product.DAL 依赖于 Common.DAL
Product.BLL 依赖于 Common.BLL 和 Product.DAL
Product.exe 依赖于 Product.BLL

这使得构建顺序如下：

Common.DAL
Common.BLL
Product.DAL
Product.BLL
Product.exe

在尝试运行应用程序时，我经常收到以下错误：

无法加载文件或程序集“Common.DAL，Version=1.0.0.0，Culture=neutral，PublicKeyToken=4e5249f2e70e1da8”或其依赖项之一。系统找不到指定的文件。

我已将问题归结为并非所有从解决方案构建的程序集最终都位于 Product.exe 的 bin\Debug 文件夹中。

如果我清理解决方案，然后重新构建它，文件将如下所示：

Common.DAL\bin\Debug 包含 Common.DAL.dll
Common.BLL\bin\Debug 包含 Common.BLL.dll 和 Common.DAL.dll
Product.DAL\bin\Debug 包含 Common.DAL.dll 和 Product.DAL.dll
Product.BLL\bin\Debug 包含 Common.BLL.dll、Common.DAL.dll、 Product.BLL.dll 和 Product.DAL.dll
但 Product.exe\bin\Debug 仅包含 Product.exe、Product.BLL 和产品.DAL。 缺少通用程序集。所以当我跑步时 Product.exe，我收到上面列出的错误。

我已经检查了我所有项目和属性的属性。他们都使用 .NET Framework 4。对我的程序集的所有引用都将“特定版本”属性设置为 false，并将“复制本地”属性设置为 true。

我可以强制通过在 Product.exe 项目中添加对 Common 程序集的引用，将缺少的程序集复制到 Product.exe\bin\Debug，但由于 Product.exe 不em>明确地使用 Common 程序集，这感觉更像是一个杂物，而不是一个解决方案。

我查看了 MSDN 和 Visual Studio 文档，看看我是否可以找出影响或影响引用程序集复制的因素，并且我已经搜索了类似问题，但我没有发现任何有用的东西。

我不知道该去哪里或下一步该做什么。

【问题讨论】：

为什么不想使用项目引用？如果你到处使用项目引用，你还有这个问题吗？
我们在几个项目中遇到过这种情况，最终使用“copylocal=true”引用了最顶层程序集（*.exe 或网站）中的所有程序集。这是一种解决方法，我也想知道这种行为的真正原因是什么。
@McKay，只有当项目都存在于同一个解决方案中时，项目引用才有效。很多时候，所有项目都不会在同一个解决方案中。 Common.DAL 和 Common.BLL 程序集通常不会在 Product.exe 解决方案中，甚至 Product.DAL 和 Product.BLL 项目也不一定必须在 Product.exe 解决方案中。
您可以做的一件事是在两个程序集中包含公共项目。
这没有意义。您不能使用任何项目引用，曾经吗？我会关注你的构建过程......

标签： c# visual-studio-2010 assemblies

【解决方案1】：

您应该只在它们相对稳定并且在解决方案之外时引用裸组件。

在您的解决方案中，从“项目”选项卡中引用它们。这将使 VS 在项目之间配置正确的依赖关系和构建顺序。

在您当前的设置中，验证项目依赖项（解决方案|属性）。

【讨论】：

我不同意。如果我这样做，那么每当我将任何项目添加到解决方案时，我要么需要添加所有 that 项目引用的项目，要么将所有这些项目引用更改为新位置。如果我对存储库文件夹中的程序集进行了所有引用，则无需更改它们，无论它们包含在哪个解决方案中。
我会和 Henk 一起去这里。如果你有很多解决方案，很多项目都被划掉了，那么你所拥有的就是意大利面条式架构。如果您有很多项目在许多解决方案中引用了项目：也许是时候考虑制作一些接口 dll 并完全采用下面的复杂实现了。使用它们之间的接口制作逻辑组件。
@zmilojko，我不太确定我是否跟随。您是说如果我引用了一个程序集，而该程序集又引用了 5 个其他程序集，我应该始终在我的解决方案中包含这 5 个其他程序集吗？那些程序集引用的任何程序集呢？
解决方案实际上不包含项目。他们引用它们。我认为你在这个假设上磕磕绊绊。是的，如果您想要最新版本的程序集，您将包括构建这些程序集所需的所有项目。相当标准的东西。
@Weltonv3.51 答案是创建一个接口库，dll 定义一个接口，然后您的“服务器”库将引用该接口。创建逻辑组件，总有一天会更容易拆分工作/外包。但是如果你还在开发，不要从二进制文件中引用dll，你肯定会遇到版本问题！

【解决方案2】：

在你的问题中你说：

我可以强制将丢失的程序集复制到 Product.exe\bin\Debug 通过添加对 Common 程序集的引用 Product.exe 项目，但由于 Product.exe 没有明确使用公共程序集，这感觉更像是一个杂物，而不是一个解决方案。

我认为我不同意。它并不完美，但 Visual Studio 有时甚至需要这种内部解决方案。这取决于您如何使用课程。

虽然您可能认为这有点笨拙，但您的其他（我敢说“笨拙”）要求（每个解决方案一个项目）似乎使事情看起来笨拙

【讨论】：

好吧，无论是否笨拙，我都必须接受这个答案，因为它对我们的开发过程影响最小。我们无法重新设计我们的构建过程以及我们目前正在开发和维护的所有项目和解决方案。感谢您的反馈。 =)