Visual Studio重建未修改的项目 [英] Visual Studio Rebuilds unmodified projects
问题描述
因此，正如标题所示，我现在有一个VS2010解决方案，其中包含约50个项目.如果我更改了没有引用的顶级"项目，那么VS仍然会重建所有50个项目.我正在运行没有任何附加组件的Visual Studio 2010 Ultimate.我正在使用ILMerge将所有项目合并到一个文件中.
我已经通过检查较低级别的dll的时间戳进行了验证，即使它们的代码未被触及，它们也确实已被重建.
我已经阅读了以下所有回复和评论:
但是其中大多数只是提供有关卸载项目的建议，以加快构建时间，但没有具体的修复方法.我试图弄清楚为什么VS认为这些依赖项目在不使用并进行修复时需要重新构建.
我打开了工具>选项>项目和解决方案>生成并运行>仅在运行时构建启动项目和依赖项"，但没有效果.
此外，如果我仅重建仅具有8个(间接)依赖项的中级"项目，那么即使未调用ILMerge并且未修改任何依赖项，它仍将构建所有8个项目. /p>
感谢大家提供的任何见解.
已添加
为了测试一些建议，我从头开始创建了一个新的WinForms项目.然后，我在该解决方案中创建了两个新项目.我将我的两个最低级别"项目中的所有代码和资源(不是项目文件)复制到了两个全新的项目中(通过将文件和文件夹从资源管理器拖放到Visual Studio中的项目中).
最低的项目(我们称为 B )没有引用任何其他项目.下一个项目 A 仅引用了 B .因此，一旦我在项目中添加了所需的.NET和外部程序集引用，就可以构建解决方案.
然后我有了新的WinForm项目参考 A ，并进行了完整的构建.因此，参考链是:
WinForm -> A -> B
然后我修改了 WinForm 仅 并进行了标准构建(F6).和以前一样，Visual Studio重建了所有三个项目.
在项目 B 中对源文件进行了系统的删除之后，我发现如果删除了Resources.Designer.cs和Resources.resx(并注释掉了使用.Properties.Resources对象的代码，这些资源)，那么对 WinForm 的修改将不再重建整个解决方案，而只会重建 WinForm .
将Resources.resx和Resources.Designer.cs添加回项目 B (但将引用的代码注释掉，以便没有任何资源使用)将重新引入完整的构建行为.
要查看我的资源文件是否损坏，我再次删除了它们，然后创建了一个新文件(通过Project Properties-> Resources)，并重新添加了与以前相同的资源，它是一个Excel文件.使用此设置，仍将进行完全重建.
然后，我删除了单个资源，但是将资源文件留在了项目 B 中.即使没有添加资源，但是资源文件仍在项目中，也会进行完全(不需要的)重建.
似乎仅将资源文件添加到(.NET 3.5)项目中，就会导致Visual Studio 2010始终重建该项目.这是错误还是预期/预期的行为?
再次感谢！
虽然我不认为这是解决方法，但这是一种适合我的情况的解决方法...
最初，我有50个项目中有5个包含Resources部分.这些项目将始终被重建，因此依赖于它们的任何东西也将被重建.这5个项目之一是基本"级别的库，其他48个项目都引用了该库，因此即使不需要它，我的项目中的96％也会每次都被重建.
我的解决方法是使用依赖项注入，接口和专用的资源"项目.我没有让这5个项目引用它们自己的Resources对象，而是在每个项目中创建了一个提供所需资源的接口.然后，需要这些资源的类将要求在其在构造函数中的创建过程中传递该接口(构造函数注入).
然后，我创建了一个单独的"Resources"项目，该项目的实际资源"部分与正常情况一样.该项目仅包含资源本身，以及通过接口提供这些资源所需的每个接口的类.该项目将引用所有其他具有资源依赖性的项目，并实现该项目所需的接口.
最后，在我的顶级"项目中，没有引用任何内容(以及exe的实际构建位置以及我的合成根目录是否存在)，我引用了"Resources"项目，将DI连接起来，然后我们就走了.
这意味着每次将仅重建两个项目(资源"和顶层")，如果我进行部分构建(Shift-F6)，则根本不会重建它们. /p>
同样，这不是一个很好的解决方法，但是每次要构建48个项目，一次构建大约需要3分钟，所以我每天不必要的重建就损失了30到90分钟.重构花费了一段时间，但我认为这是一笔不错的投资.
这是简化图.请注意，为了减少混乱，没有显示从Main.exe到Proj1和Proj2的依赖性.
通过这种设计，我可以构建Proj1或Proj2而不触发完全重建，因为它们对Resources部分没有任何依赖关系.只有Main知道Resources的实现.
So, as the title reads, I have a VS2010 solution with ~50 projects in it right now. If I make a change to a "top level" project that nothing references then VS still rebuilds all 50 projects. I'm running Visual Studio 2010 Ultimate without any add-ons. I am using ILMerge to consolidate all of the projects into a single file.
I have verified this by checking the time stamps of the lower level dlls and see that they are indeed rebuilt even though their code wasn't touched.
I've read all responses and comments for:
Visual Studio 2008 keeps rebuilding
Visual studio keeps building everything
Strange VS2010 build glitch occurs in my solution
Reasons for C# projects to rebuild in Visual Studio
But most of them just offer suggestions on unloading projects to speed up build times but nothing concrete as to a fix. I'm trying to figure out why VS thinks these dependent projects need to be rebuilt when they don't and fix it.
I've turned on 'Tools > Options > Projects and Solutions > Build and Run > Only build startup projects and dependencies on run' but with no effect.
Also, if I just rebuild a "mid-level" project that only has 8 (in)direct dependencies then it still builds all 8 projects even though ILMerge isn't invoked and none of the dependent projects have been modified.
Thank you everyone for any insight you may be able to provide.
Added
To test some of the suggestions I created a new WinForms project from scratch. I then created two new projects inside that solution. I copied all of the code and resources (not project file) from my two 'lowest level' projects into the two brand new projects (I did this by dropping the files and folders from Explorer onto the project in Visual Studio).
The lowest project, let's call it B, did not reference any other project. The next project, A, referenced B only. So once I added the required .NET and external assembly references to the projects then the solution would build.
I then had my new WinForm project reference A and did a full build. So the ref chain is:
WinForm -> A -> B
I then modified WinForm only and did a standard build (F6). As before, Visual Studio rebuilt all three projects.
After some systematic eleminiation of source files in project B I found that if I removed my Resources.Designer.cs and Resources.resx (and commented out the code that made use of the .Properties.Resources object of those resources) then a modification of WinForm would no longer rebuild the entire solution and would only rebuild WinForm.
Adding the Resources.resx and Resources.Designer.cs back to project B (but leaving the referenced code commented out so that nothing was making use of the resources) would re-introduce the full build behavior.
To see if perhaps my resource files were corrupted, I deleted them again and then created a new one (via Project Properties -> Resources) and re-added the same resource as before, which was a single Excel file. With this setup the full rebuild would still occur.
I then removed the single resource, but left the resource file in project B. Even with no resources added, but the resource file still in the project, the full (unneeded) rebuild would occur.
It appears that just having a resource file added to a (.NET 3.5) project will cause Visual Studio 2010 to always rebuild that project. Is this a bug or intended/expected behavior?
Thanks all again!
While I don't think this is a fix, it is a workaround that has worked for my situation...
I originally had about 5 projects out of 50 that contained a Resources section. These projects would always be rebuilt and thus anything that they depended on would also be rebuilt. One of those 5 projects was a "base" level library that 48 of the other projects referenced, thus 96% of my project would be rebuilt every time even if it didn't need it.
My workaround was to use dependency injection, interfaces, and a dedicated "Resources" project. Instead of having those 5 projects reference their own Resources object, I created an interface in each project that would supply the desired resources. Then, the classes that needed those resources would require that interface be passed in during their creation in the constructor (constructor injection).
I then created a separate "Resources" project that had an actual Resources section like normal. This project only contained the resources themselves, and a class for each interface that was needed to provide those resources via an interface. This project would reference every other project that had a resource dependency and implement the interface that the project needed.
Finally, in my "Top Level" project which nothing referenced (and where the exe was actually built and my composition root lives) I referenced the "Resources" project, wired up the DI, and away we went.
This means that only two projects (the "Resources" and the "Top Level") will be rebuilt every time, and if I do a partial build (Shift-F6) then they won't get rebuilt at all.
Again, not a great work around, but with 48 projects being built every time a build would take about 3 minutes, so I was losing 30 to 90 minutes a day with needless rebuilds. It took awhile to refactor, but I think it was a good investment.
Here is a simplified diagram. Note that the dependencies from Main.exe to Proj1 and Proj2 are not shown in order to reduce clutter.
With this design, I can do a build of Proj1 or Proj2 without triggering a full rebuild, since they don't have any dependencies on a Resources section. Only Main knows about the Resources implementation.
这篇关于Visual Studio重建未修改的项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
