I have a visual studio (2005) solution file with 70 projects.
Each time I press F5 to run it, it tells me that 4 of the projects are out of date, and asks me if I want to rebuild them. It does this even though I have just done a full build.
I understand (in principle) that one of the other projects must update something that these projects depend on, but how do I go about finding out what?
我有一个包含70个项目的visual studio(2005)解决方案文件。每次我按F5运行它,它告诉我4个项目已经过时,并询问我是否要重建它们。即使我刚刚完成了一个完整版本,它也会这样做。我理解(原则上)其中一个项目必须更新这些项目所依赖的内容,但我该如何找到什么?
Are there any tools to help, or what procedure should I follow to figure out what is causing VS to flag these projects for a rebuild?
是否有任何工具可以提供帮助,或者我应该遵循哪些程序来找出导致VS标记这些项目以进行重建的原因?
UPDATE:
For those interested it looks like my PC was/is the problem (my HD has been acting up recently). As I tried to track down the problem successive rebuilds started generating compile errors. I did a clean-and-build and got a huge number of (obviously spurious) errors. One reboot later, followed by a rebuild, all the errors and the dependency problem have gone away.
Excuse me now, while I go and back-up all my important files...
更新:对于那些感兴趣的人,看起来我的电脑是/是问题(我的HD最近一直在表现)。当我试图追踪问题时,连续的重建开始产生编译错误。我做了一个干净的构建,并得到了大量(显然是虚假的)错误。稍后重启一次,然后重建,所有错误和依赖性问题都消失了。对不起,我去备份所有重要文件...
5 个解决方案
#1
I would run a normal Build, twice in a row. The second time, I'd set the MSBUILD verbosity to "Normal" or higher (in Tools->Options, "Projects and Solutions", "Build and Run". I'd read the output carefully to see what gets actually built the second time.
我会连续两次运行一个正常的Build。第二次,我将MSBUILD详细程度设置为“正常”或更高(在工具 - >选项,“项目和解决方案”,“构建和运行”中。我仔细阅读输出以查看实际构建的内容第二次。
In fact, now that I think of it, if this really is a cycle, then some part of what gets built the second time must be what's causing it to build the third time, etc. Perhaps you have a post-build step in one of the projects that touches an assembly or other resource used as input to an earlier step. With 70 projects in the solution, something like this would be easy to cause inadvertently, and hard to catch. You may have to learn enough about MSBUILD to be able to detect when one of its steps is deciding it needs to build because something changed, then to understand your solution well enough to know that nothing should have changed; then to see that something has changed that should not have changed.
事实上,现在我想起来,如果这真的是一个循环,那么第二次构建的东西的某些部分必须是导致它第三次构建的原因,等等。也许你有一个后构建步骤接触用作前一步骤输入的程序集或其他资源的项目。在解决方案中有70个项目,这样的事情很容易在不经意间造成,而且难以捕捉。您可能需要充分了解MSBUILD,以便能够检测其中一个步骤决定是否需要构建因为某些内容发生了变化,然后很好地理解您的解决方案,以便知道什么都不应该更改;然后看到一些不应该改变的东西已经改变了。
When you're done with this exercise, you may have gained some insight that will enable you to help in breaking the solution into smaller solutions.
完成本练习后,您可能已经获得了一些见解,可以帮助您将解决方案分解为更小的解决方案。
#2
I had the same problem with linking a .netmodule into my project that was complied with a custom build step. The prolem turned out to be that I was also linking a C++ lib and the .netmodule file was listed on the same line in the linker input.
将.netmodule链接到我的项目中时遇到了同样的问题,该项目符合自定义构建步骤。原来的结果是我也链接了一个C ++ lib,而.netmodule文件列在链接器输入的同一行。
Example: .lib .netmodule
示例:.lib .netmodule
Insead of: .lib \n .netmodule
Insead:.lib \ n .netmodule
#3
A quicker way than John's log verbosity in Visual Studio 2013, is to open the Solution Explorer's project tree; the files which were not found won't have the little triangle in front of the filename (with which you normally can see a list of symbols in that file).
比John在Visual Studio 2013中的日志详细程度更快的方法是打开Solution Explorer的项目树;未找到的文件在文件名前面没有小三角形(通常可以在其中看到该文件中的符号列表)。
Remove those files and for me, the AlwaysCreate message went away (you only see 'AlwaysCreate' when the verbose level is set to at least 'Normal').
删除这些文件,对我来说,AlwaysCreate消息消失了(当详细级别设置为至少'正常'时,您只看到'AlwaysCreate')。
#4
I had this problem and it turned out I had a header file added to my project but that I had deleted from the disk. Removing the non-existent header file from the fixes the behavior.
我有这个问题,事实证明我有一个头文件添加到我的项目,但我已从磁盘中删除。从修复行为中删除不存在的头文件。
#5
I had this exact problem in VS2010 after I deleted some source files that were no longer used in my project. Simply selecting "Clean Solution" from the "Build" menu and then rebuilding the solution fixed the problem for me.
在我删除了一些在我的项目中不再使用的源文件后,我在VS2010中遇到了这个问题。只需从“Build”菜单中选择“Clean Solution”,然后重建解决方案就可以解决问题。
#1
I would run a normal Build, twice in a row. The second time, I'd set the MSBUILD verbosity to "Normal" or higher (in Tools->Options, "Projects and Solutions", "Build and Run". I'd read the output carefully to see what gets actually built the second time.
我会连续两次运行一个正常的Build。第二次,我将MSBUILD详细程度设置为“正常”或更高(在工具 - >选项,“项目和解决方案”,“构建和运行”中。我仔细阅读输出以查看实际构建的内容第二次。
In fact, now that I think of it, if this really is a cycle, then some part of what gets built the second time must be what's causing it to build the third time, etc. Perhaps you have a post-build step in one of the projects that touches an assembly or other resource used as input to an earlier step. With 70 projects in the solution, something like this would be easy to cause inadvertently, and hard to catch. You may have to learn enough about MSBUILD to be able to detect when one of its steps is deciding it needs to build because something changed, then to understand your solution well enough to know that nothing should have changed; then to see that something has changed that should not have changed.
事实上,现在我想起来,如果这真的是一个循环,那么第二次构建的东西的某些部分必须是导致它第三次构建的原因,等等。也许你有一个后构建步骤接触用作前一步骤输入的程序集或其他资源的项目。在解决方案中有70个项目,这样的事情很容易在不经意间造成,而且难以捕捉。您可能需要充分了解MSBUILD,以便能够检测其中一个步骤决定是否需要构建因为某些内容发生了变化,然后很好地理解您的解决方案,以便知道什么都不应该更改;然后看到一些不应该改变的东西已经改变了。
When you're done with this exercise, you may have gained some insight that will enable you to help in breaking the solution into smaller solutions.
完成本练习后,您可能已经获得了一些见解,可以帮助您将解决方案分解为更小的解决方案。
#2
I had the same problem with linking a .netmodule into my project that was complied with a custom build step. The prolem turned out to be that I was also linking a C++ lib and the .netmodule file was listed on the same line in the linker input.
将.netmodule链接到我的项目中时遇到了同样的问题,该项目符合自定义构建步骤。原来的结果是我也链接了一个C ++ lib,而.netmodule文件列在链接器输入的同一行。
Example: .lib .netmodule
示例:.lib .netmodule
Insead of: .lib \n .netmodule
Insead:.lib \ n .netmodule
#3
A quicker way than John's log verbosity in Visual Studio 2013, is to open the Solution Explorer's project tree; the files which were not found won't have the little triangle in front of the filename (with which you normally can see a list of symbols in that file).
比John在Visual Studio 2013中的日志详细程度更快的方法是打开Solution Explorer的项目树;未找到的文件在文件名前面没有小三角形(通常可以在其中看到该文件中的符号列表)。
Remove those files and for me, the AlwaysCreate message went away (you only see 'AlwaysCreate' when the verbose level is set to at least 'Normal').
删除这些文件,对我来说,AlwaysCreate消息消失了(当详细级别设置为至少'正常'时,您只看到'AlwaysCreate')。
#4
I had this problem and it turned out I had a header file added to my project but that I had deleted from the disk. Removing the non-existent header file from the fixes the behavior.
我有这个问题,事实证明我有一个头文件添加到我的项目,但我已从磁盘中删除。从修复行为中删除不存在的头文件。
#5
I had this exact problem in VS2010 after I deleted some source files that were no longer used in my project. Simply selecting "Clean Solution" from the "Build" menu and then rebuilding the solution fixed the problem for me.
在我删除了一些在我的项目中不再使用的源文件后,我在VS2010中遇到了这个问题。只需从“Build”菜单中选择“Clean Solution”,然后重建解决方案就可以解决问题。