如果右击引用的程序集，将看到名为Copy Local的属性。如果“本地复制”设置为true，则程序集应该包含在bin中。然而，Visual studio有一个问题，有时它不包括在bin文件夹中引用的dll…这是对我有效的变通方法:

如果右击引用的程序集，将看到名为Copy Local的属性。如果“本地复制”设置为true，则程序集应该包含在bin中。然而，Visual studio有一个问题，有时它不包括在bin文件夹中引用的dll…这是对我有效的变通方法:

也遇到了同样的问题。背景信息:在构建之前，我已经向解决方案添加了一个新的项目X。Y项目依赖于X项目，A、B、C项目依赖于Y项目。

构建错误是无法找到项目A、B、C、Y和X dll。

根本原因是新创建的项目X针对。net 4.5，而其余的解决方案项目针对。net 4.5.1。项目X没有建立，导致其他项目也没有建立。

确保任何新添加的项目与解决方案的其余部分目标相同。net版本。

将DLL作为现有项添加到其中一个项目中，应该对其进行排序

在我的例子中，这是最愚蠢的事情，由TFS/VS的默认行为引起的，我不同意。

由于添加dll作为主项目的引用没有工作，我决定将其添加为“现有项”，复制本地=始终。即使那时文件也不在那里。

事实证明，即使文件出现在VS解决方案中，并且在本地和服务器上编译了所有内容，VS/TFS并没有将该文件添加到源代码控制中。它根本不包括在“未决更改”中。我不得不手动打开源代码管理资源管理器，并明确地单击“将项目添加到文件夹”图标。

愚蠢，因为我已经在vs中开发了15年，我以前遇到过这种情况，我只是不记得了，不知为何我错过了它，因为所有东西仍然编译，因为文件是常规引用，但被添加为Existing Item的文件没有被复制，因为它不存在于源代码控制服务器上。

我希望这能节省一些时间，因为我失去了2天的生命。

确保您使用的依赖DLL的目标. net框架不高于项目应用程序的目标. net框架。

你可以通过选择你的项目来检查，然后按ALT+ENTER，然后从左边选择Application，然后选择项目的目标框架。

假设, 依赖DLL目标框架= 4.0和 应用程序DLL目标框架= 3.5然后将其更改为4.0

谢谢你！