Visual Studio“重建所有失败”

Question

为什么Rebuild会在没有错误的情况下失败？

从今天早晨开始，此错误不断出现。我构建了整个解决方案（25个C＃托管项目），并出现“Rebuild All failed”，但没有任何错误！ （我有13个关于COM不支持泛型的警告，但它是“正常的”，因为一个dll暴露为COM。）

Answer 1

本身不是答案 - 但你最好还是看一下输出窗口，看看它在那里说了什么。

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

注意 - 最高级别会生成大量信息。

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

Answer 2

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

发生此错误时，保存项目并关闭VS 2013.之后，重新打开VS2013并打开上一个项目。

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

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

Answer 3

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

关闭解决方案，删除其.suo（.v12.suo for VS2012 +），重新打开解决方案，Visual Studio将构建一个新解决方案。您将丢失StartUp项目，断点，书签，哪些文件是打开的，哪些项目/文件夹是扩展的等等。但与未构建的解决方案相比，这一切都很小！

Answer 4

这是支票清单＆amp;如果我是你，我会做的事情（尝试在每一步之后建立）：

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

Answer 5

选择适当的目标框架
-右键点击项目
-属性
-在“应用程序”标签中，选择目标框架

Answer 6

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

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

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

Answer 7

很久以前我修复了.NET Framework安装（在我的案例中是.NET Framework v4.0 Extended）。

Answer 8

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

Answer 9

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

Answer 10

我刚刚遇到这种情况，并意识到我在代码中留下了一条'#error'行并忘了它。当我尝试构建时，构建失败但#error行没有显示在我的错误中。

尝试搜索所有'#error'

Answer 11

解决方案： 由于未为调试设置先决条件，因此仅针对发行版进行设置 01-更改解决方案配置（在主屏幕中） 设置（调试释放） 将解决方案平台设置为（任何CPU） 02-设置调试先决条件（如果要在调试模式下继续） 为所有项目设置03个目标平台版本

Answer 12

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

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

Answer 13

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

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

完成此操作后，我开始遇到此问题。构建一直进行到最后一个阶段，然后毫无错误地失败了。输出只显示成功。

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

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

这可能不是您的确切原因，但似乎您也有一些名称冲突或部署问题。毫不奇怪，编译器不会给您错误，因为在编译阶段没有问题，麻烦始于部署，显然这显然不是显而易见的。

Answer 14

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

Answer 15

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

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

我点击了我的帐户，重新输入了我的凭据，并重建了解决方案。

Voila！构建解决方案时，我得到了我曾经见过的东西-所有错误中都有很多错误。

希望这对某人有帮助。

Answer 16

这个错误对我来说似乎有点普遍。我也经历了这种情况，但是我设法解决了这里提到的任何问题。

我有一个项目和几个依赖项。这些依赖项之一发生了变化。

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

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

尽管构建依赖关系配置正确。在发布模式下编译时，主项目找不到在辅助项目中创建的新方法。 因此，我必须在发布模式下一个一个地重新编译每个辅助项目。之后，我重新编译了主项目，一切正常。

希望它对某人有帮助！

Answer 17

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

Answer 18

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

Answer 19

我遇到了同样的问题。我试图引用更高的.net框架版本（4.5.2）来降低.net框架版本（4.5），这导致了构建错误。我在两个项目中都使版本相同并且有效。

Answer 20

1. 清理解决方案
2. 尝试并构建每个项目并查看问题所在。
3. 检查每个参考（每个项目）以确保没有黄色警告标志

解决方案有没有建成？

Answer 21

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

Answer 22

一旦我们尝试重新命名服务引用名称，我们会在服务引用中给出一些其他名称，但在命名空间中它会引用旧名称，所以如果你删除并添加一个服务引用然后保持相同的名称，否则我们可能会遇到此错误，但我们可以在输出窗口中看到错误。

Answer 23

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

1. 开始
2. 运行...
3. Appwiz.cpl
4. （查找已安装的Visual Studio版本）
5. 右键单击
6. 更改
7. 修复

Answer 24

我通过转到数据库项目/项目设置并注意到目标平台是SQL Server 2014而不是2012应用程序来修复它在我的Visual Studio 2013新实现上。