Visual Studio“重建全部失败”

Question

为什么重建失败且没有错误？

从今天早上开始，这个错误不断出现。 我构建了整个解决方案（25 个 C# 托管项目）并出现“全部重建失败”，但没有任何错误，（我有 13 个关于 COM 不支持 Generics 的警告。但它是“正常的”，因为一个 dll 作为 COM 公开。）

Answer 1

本身不是答案 - 但你最好查看输出窗口并查看它在那里说的内容。

此外，为了帮助您解决这个问题，您可能需要查看您的 MSBuild 详细程度 - 如此屏幕截图所示（最后两个选项）：

当心 - 最高级别会产生大量信息。

最后 - 在命令提示符下从解决方案文件夹运行msbuild将真正解决问题 - 因为错误消息和警告分别以红色和黄色显示。

Answer 2

我找到了自己的解决方案，这很简单：

出现这个错误时，保存项目并关闭VS 2013。之后，重新打开VS2013并打开最后一个项目。

它就像一个魅力。 但是每次都很烦！

许多人在VS2010、VS2012和VS2013中报告了这个问题。

Answer 3

可能是损坏的解决方案用户选项文件。

关闭解决方案，删除其 .suo（VS2012+ 为 .v12.suo），重新打开解决方案，Visual Studio 将构建一个新的。 您将丢失启动项目、断点、书签、打开的文件、展开的项目/文件夹等。但与未构建的解决方案相比，这些都微不足道！

Answer 4

我有同样的问题。 我试图将更高的 .net 框架版本（4.5.2）引用到导致构建错误的较低的 .net 框架版本（4.5）。 我在两个项目中制作了相同的版本并且它有效。

Answer 5

您是否尝试在重新构建之前清洁解决方案？

Answer 6

这是检查清单和如果我是你我会做的事情（尝试在每个步骤之后构建）：

• 错误列表是否已激活？ （有时我忘记激活，我只能看到警告和消息）
• 检查输出窗口是否有错误消息..
• 清洁溶液。
• 清洁后仔细检查所有内容是否已从调试文件夹中删除。
• 在发布模式下构建它。
• 构建解决方案项目到项目，直到您隔离有问题的项目。
• 删除 COM 和注释代码，看看这是否是问题的根源。
• 重启VS2010。
• 重新启动窗口。

Answer 7

不久前，我通过修复 .NET Framework 安装（在我的情况下为 .NET Framework v4.0 Extended）修复了它。

Answer 8

我在 VS 2015 中遇到了同样的问题。我尝试了以下但没有成功：

1. 关闭 VS 项目并重新打开
2. 关闭所有打开的 VS 项目并重新打开有问题的项目
3. 清洁液
4. 重建解决方案
5. 删除 bin\\debug 和 bin\\release 中的所有文件

最后我尝试了Keith Robertson 的回答，删除.suo ( \\Visual Studio 2015\\Projects\\[ProjectName]\\.vs\\[ProjectName]\\v14\\.suo )。 虽然这并没有让我得到一个好的构建，但它最终给了我一条错误消息，指出我的应用程序有两个入口点。 我转到应用程序属性（Alt + Enter）并从下拉列表中选择一个启动对象。

Answer 9

检查输出窗口（查看 -> 输出），因为它会告诉您出了什么问题。 有时，可能会缺少引用，或者解决方案中某个项目的目标 .NET 版本存在问题。

Answer 10

选择合适的目标框架
- 右键单击​​项目
- 特性
- 在应用程序选项卡中，选择目标框架

Answer 11

我只是有同样的事情。 对我来说，它有助于重新启动 VS 并以管理员身份运行它。

Answer 12

1. 清洁溶液
2. 尝试构建每个项目，看看问题出在哪里。
3. 检查每个参考文献（每个项目的）以确保没有黄色警告标志

解决方案是否曾经构建过？

Answer 13

我刚刚发生了这种情况，并意识到我在代码中留下了“#error”行并忘记了它。 当我尝试构建时，构建失败但 #error 行没有出现在我的错误中。

尝试搜索所有“#error”

Answer 14

我通过转到数据库项目/项目设置并注意到目标平台是 SQL Server 2014 而不是 2012 就像它应该的那样，在我的 Visual Studio 2013 的新实现上修复了它。

Answer 15

我今天遇到了类似的问题，并通过修复修复了它。

1. 开始
2. 跑…
3. Appwiz.cpl
4. （找到您安装的 Visual Studio 版本）
5. 右键点击
6. 改变
7. 修理

Answer 16

一旦出现此错误的机会是当我们尝试重新命名服务引用名称时，我们会在服务引用中指定其他名称，但在命名空间中的某些位置将引用旧名称，因此如果您删除并添加服务引用然后保持相同的名称，否则我们可能会遇到此错误，但我们可以在“输出”窗口中看到错误。

Answer 17

这显然有很多原因。 我刚刚找到了我的问题的原因：我创建的新项目的.NET版本高于顶级项目的版本。 （4.5.2 对 4.0）

Answer 18

就我而言，这是计算机的错误日期和时间。

Answer 19

这个错误对我来说似乎有点通用。 我也经历过这种情况，但我设法以不同于这里提到的任何一种方式解决它。

我有一个项目和几个依赖项。 其中一个依赖项发生了变化。

在调试模式下编译主项目时，我验证了一切正常。 但是，切换到发布模式并重新编译出现问题。 Rebuild all failed和0 Errors

通过分析调试输出，我遇到了一个错误：

尽管构建依赖项配置正确。 在发布模式下编译时，主项目没有找到在副项目中创建的新方法。 所以我不得不在发布模式下一个一个地重新编译每个二级项目。 之后，我重新编译了主项目，一切正常。

希望它可以帮助某人！

Answer 20

我没有收到任何反馈/消息/错误。 只是所有项目都无法构建。

我关闭并再次尝试 - 我注意到一个错误，提示“您无权访问......”

我单击了我的帐户，重新输入了我的凭据，然后重新构建了解决方案。

瞧！ 当我构建一个解决方案时，我得到了我习惯看到的东西——在他们所有的荣耀中都有很多错误。

希望这可以帮助某人。

Answer 21

这是一些人可能耳熟能详的另一个原因。 我已经将一些代码集成到我的解决方案中，这些代码包装了一个 DLL。 随附的 C# 代码文件提供了一个很好的托管 API，并处理了访问 DLL 的低级 LoadLibrary 内容。 两者都有相同的基本名称，所以我有 SomeName.cs 和 SomeName.dll。 我可以将它放入任何项目中，它会起作用。

一段时间后，这不太好，因为我开始在不同的项目中使用它。 我在多个项目中获得了 DLL 和包装器代码的副本。 所以我认为最好将包装器代码和 DLL 放入一个新的类库项目中，然后从其他项目中引用该新项目。

完成后，我开始遇到这个问题。 构建一直进行到最后一个阶段，然后没有错误地失败。 输出只显示成功。

问题是包装类库项目的名称。 我为此使用了相同的基本名称 (SomeName)。 默认情况下，程序集名称将是 SomeName.dll 并且我已经有一个这样的文件（要包装的 DLL），因此我与输出文件发生了冲突。

将包装项目及其输出程序集重命名为 SomeNameWrapper 后，问题就消失了。

这可能不是您的确切原因，但您似乎也有一些名称冲突或部署问题。 编译器不会给你错误也就不足为奇了，因为在编译阶段没有问题，问题从部署开始，显然这不会以明显的方式出现。

Answer 22

我遇到了同样的问题，原始海报显示 0 个错误并且重建都成功了。 “输出”选项卡显示一条消息，指出引用的 dll 是使用更高版本的 .NET Framework 构建的。

更改 .NET 框架以匹配解决了我遇到的问题，错误为 0，重建全部成功。

Answer 23

解决方案：因为没有为调试设置先决条件，仅针对版本01-更改解决方案配置（在主屏幕中）设置（调试到发布）将解决方案平台设置为（任何CPU）02-设置调试的先决条件（如果您想继续调试模式) 03-为所有项目设置目标平台版本

Answer 24

您的解决方案中包含的某些文件不在正确的目录中，或者您更改了应用程序中一个或多个目录的名称。 在“设置”下的解决方案资源管理器中，查看所有文件的列表，并删除未在 SourcePath 属性中正确列出的文件。

Answer 25

我对 View 文件的依赖之一导致了这个。 检查您的视图文件是否有任何尚未注入的依赖项。