我在Visual Studio 2010中有一个带有大量项目的.NET解决方案。直到最近,当我从IDE中运行启动项目时,只有在启动项目或其中一个依赖项目中对代码进行了更改时才会构建项目。
大约两周前,我注意到每次运行启动项目时,Visual Studio都会构建所有项目,大约需要7分钟。毋庸置疑,这需要花费大量时间,而且我已经尽力在网上寻找解决方案,但还没有找到解决我特定问题的解决方案。
一些额外的信息 - 在我开始遇到这个问题的同一时间,同样的问题开始发生在我的团队中的其他人身上。
我们也在使用源代码存储库。由于我们没有更改Visual Studio中的任何设置,我怀疑有人无意中更改了某些项目的源代码中的某些内容,现在每个项目都需要构建。
任何建议都将不胜感激。
答案 0 :(得分:13)
原因可能很多,所以没有你的解决方案+项目,我们只能猜测。
我处理这个问题的典型方法是通过二进制搜索缩小范围。也就是说,
这(当然)仅在有一个项目引入新问题时才有效(可能)。
在我的特定情况下,其中一个罪魁祸首是x64项目参考x86项目未被选中在x64配置中构建。
答案 1 :(得分:6)
我将分享我在stackoverflow上找到的最佳答案,并结合亚特史密斯在这里接受的答案,我已经找到了问题的根本原因:
通过将Visual Studio配置为以“诊断”方式记录构建输出,如本答案中所述:https://stackoverflow.com/a/29649259/2740778,输出的第一行解释了MSBuild确定重建项目的原因。
所以,如果你有,让我们说3个项目进入解决方案:
以这种方式引用:应用程序引用Library1,这个引用了Library0。通过为Application项目选择“Build”,它第一次应该按顺序构建所有引用的项目。但是从现在开始,如果没有进行任何更改,按下“Build”不应构建任何内容,因为MSBuild会检测到未进行更改的情况。应显示类似的日志输出:
==========构建:0成功,0失败,3最新,0跳过==========
但是现在,如果进行了更改,如果在“Diagnostic”上有MSBuild日志输出级别,则输出窗口中的第一行将显示Visual Studio决定构建的原因一个项目,就像这里:
项目'Library0'不是最新的。输出文件'c:\ Library0 \ bin \ Debug \ Library0.pdb'后输入文件'c:\ Library0 \ Class1.cs'被修改。
答案 2 :(得分:5)
转到工具 - >选项 - >项目和解决方案 - >构建并运行。 看看那里的选项。 “应该只检查在Run上构建启动项目和依赖项。”
此外,您可以将构建输出(在相同的选项屏幕中)设置为详细或诊断,以查看是否可以找到每次构建项目的原因。
答案 3 :(得分:3)
根据我对这个问题的经验,只有一些项目重建,并且在最终成功之前重建失败了好几次。这显然是由\rootprojectdir\.vs\%projectname%\v14\.suo
文件被破坏引起的。这也导致相同的项目需要重建,并且每次打开VS时都会打开相同的窗口。删除.suo文件(VS关闭时)并重新打开VS修复它:)
答案 4 :(得分:2)
工具 - >选项 - >项目和解决方案 - >建立并运行
将输出详细程度设置为“Diagnostic”。进行另一次构建后,检查输出窗口。在每个项目构建开始时,构建系统将告诉您哪个依赖项导致项目构建。
(在我的情况下,它是一个意外设置为Build Action: Resource
和Copy To Output: Copy if newer
的.ico文件。很难找到。)
答案 5 :(得分:2)
对于 SDK 风格的项目,现在还有“项目和解决方案”->“SDK 风格的项目”->“日志级别”。调试增量构建时,将其设置为“详细”。
在我的例子中,由于 AutoGenerateBindingRedirects 预计会有 .dll.config
,但没有找到。这导致增量构建失败。最后它是 Visual Studio 中的一个错误,并通过删除一些与项目相关的缓存文件来解决。
答案 6 :(得分:0)
如果每次我首先检查我的设置(已经提到过)时Visual Studio都需要完整的构建,那么我会检查VS使用的条件来确定需要构建的内容。我知道在检查需要构建的内容时,VS会检查所有输入文件的时间戳。我已经看到链接生成的文件每次都会导致所有下游依赖项构建的情况,即使生成的文件的内容相同。这是MSDN增量构建的链接。
http://msdn.microsoft.com/en-us/library/ms171483.aspx
我不确定VS是否还有其他条件来识别需要构建的项目。
答案 7 :(得分:0)
我降落在这里寻找适合自己情况的解决方案,但没有一个答案可以解决。
经过调查,我发现如果Copy to Output Directory
文件上的Copy always
属性值设置为Copy if newer
或xaml
,则每次都会编译UWP项目。过去,这将有助于解决某些编译问题,但是,由于在这些文件中引入了xbf
,这些值迫使Visual Studio每次都进行重新编译,即使没有任何源代码更改。
我写了一篇关于它的博客文章:Preventing Visual Studio Recompiles in UWP
我希望这对某人有帮助。
答案 8 :(得分:0)
MSBuild检测出重建项目的需求可能有很多原因。
就我而言,我有一堆预构建事件,这些事件可以从XSD文件生成代码。这些使项目每次都被重建。然后也将重建依赖于此的其他项目。
答案 9 :(得分:0)
只是找到了另一个重建原因(至少对于新的sdk样式的项目文件,没有尝试用于“旧样式”的项目):如果.csproj文件中的TargetFramework
元素不匹配app.config中supportedRuntime
条目的sku属性,Visual Studio也会每次都重新构建项目。
例如,在.csproj中定位4.6.2
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
</PropertyGroup>
</Project>
vs。在app.config中指定的4.6.1
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
</startup>
</configuration>
将触发重建。
答案 10 :(得分:0)
就我而言,原因是我从Linux重启到Windows后未同步系统时间。
答案 11 :(得分:0)
我有一个独特的情况,我的某些源文件来自未来。我需要通过更改系统时间来测试一些代码,并在将来的日期中修改代码。然后,当我切换回显示这些文件时,导致每次运行都重新构建项目。解决方案很简单,创建一个新文件,然后在其中复制那些修改后的文件的内容。
答案 12 :(得分:0)
低级项目中的“我的配置”标签(即许多其他项目所依赖的标签)具有3个条目:
<Configurations>Debug;Release;Debug31</Configurations>
我一直在尝试一种新配置(Debug31),却忘了它。从项目文件中删除Debug31配置可以解决此问题。请注意,包含我所有项目的解决方案都没有Debug31配置。即使我仅构建“ Debug”或“ Release”,这似乎也导致该项目总是过时。为什么我不确定。
答案 13 :(得分:-1)
以下内容对我有用。 转到“属性”->“ Custom_Build_Step”,然后删除“描述”字段中的所有内容。