这里解释的大多数方法都不能为我解决这个问题。

最后，我通过以下步骤解决了这个问题:

1. 关闭Visual Studio。

2. 删除每个项目的bin文件夹中的所有内容。

3.开放解决方案并重新构建。

很多答案听起来像是反复试验。在我的例子中，它很简单:在那个特定的位置没有找到引用的dll。

如果您看到构建错误(通常在这种情况下)，则构建会报错许多dll。关键是找到丢失的正确dll。在我的例子中，我的解决方案中的一个项目有一个直接的dll引用而不是项目引用。因此，我需要在构建失败的解决方案之前构建输出该dll的项目，以确保失败的解决方案在该特定位置找到丢失的dll。

哇. .这很简单，但很难用语言表达出来。

我也被这个问题困扰着，但在尝试了之前的答案后，唯一对我有用的是逐个打开我的解决方案中的每个项目并单独构建它们。

然后我关闭Visual Studio 2013，重新打开我的解决方案，它编译良好。

这很奇怪，因为如果我在解决方案资源管理器中单击每个项目并试图以这种方式构建它们，它们都失败了。我必须单独打开它们各自的解。

我在Visual Studio 2012中有很多项目的解决方案中遇到了这个问题。以与项目构建顺序相同的顺序手动重新构建解决方案中的每个项目(在解决方案资源管理器中右键单击并重新构建)为我修复了它。

最终我找到了一个给我一个编译错误的程序。我修复了错误，解决方案将在此之后正确构建。

在Visual Studio的新版本中仍然会发生这种情况(我刚刚在Visual Studio 2013中发生了这种情况):

另一种方法是关闭Visual Studio并删除.sln文件旁边的.suo文件。(它将在下次保存全部(或退出Visual Studio)时重新生成)。

当我在另一台机器上向解决方案中添加新项目时，我就遇到过这个问题，但.suo文件在其他情况下也可能被损坏，导致非常奇怪的Visual Studio行为，所以删除它是我一直尝试的事情之一。

注意，删除.suo文件将重置解决方案的启动项目。

关于.suo文件的更多信息在这里。

在我的案例中，这是由. net框架版本不匹配引起的。

一个项目是3.5，另一个项目是4.6.1。