This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Visual Studio keeps building everything
Visual Studio 2008 keeps rebuilding the entire project as if every implementation file was modified. This happens even if no files were modified. Hit build button twice in row, and the entire projects gets rebuild twice. This doesn't happens on another box. The OS is Windows Vista.
This is very annoying. What could cause such a behavior?
It is a C++ project.
Some ideas to try...
As #David Paxson said in the comments, with some languauges (e.g. C#, VB) all the projects will appear to be "built", but the compiler will skip through the ones that don't need to be built much more quickly, even though they are still listed in the output. So it may simply appear to be rebuilding everything. Also, with C#, Visual Studio sometimes runs the project several times in a row, and sometimes it will decide for no obvious reason that it needs to "rebuild" the projects, but this only usually takes a few seconds extra unless you have hundreds of projects.
Restart Visual Studio (or even reboot the PC entirely).
Do a "Rebuild All" of the entire solution to clean out any old cached information and ensure all the output files are up to date.
If you use source control, then even better is to check in all of your changes, then delete your old source code folder (or safer, rename it somewhere out of the way until you know you don't need it) and force-get all the latest source code from source control again. This means you have a totally clean starting point (a clean or rebuild-all doesn't quite clean everything away, unfortunately). I do this every 2-4 weeks to keep everything running smoothly and totally in sync with the Source Control code.
If anything modifies the datestamps of any files in your build, then this could trigger a "need" to rebuild everything. Check that your system clock is set correctly, that there aren't any datestamps of source files set to times "in the future", and there are no applications running that could possibly "touch" any of your source files.
Check this option: Tools->Options > Projects and Solutions > Build and Run : "Only build startup projects and dependencies on Run". If it is unchecked, then VS will try to rebuild all projects every time, rather than only the dependencies of the startup project. If you have a large solution with a bunch of mostly unrelated projects in it, this is a very helpful option to set.
If there are projects that you don't need to build every time, then use the Configuration Manager to disable building of those projects in your current build (or create a "Debug Fast Build" configuration so you can switch quickly between a full rebuild and a partial build). Or move projects that don't need to be built often into a separate "libraries" solution and reference/link the output files (obj or dll) form your application's Solution, so the libraries only need to be rebuilt if you edit their code.
Lastly, make sure you're doing a "Build" and not a "Rebuild" :-)
Related
I'm using premake5 here.
It generates my solution/project files, when this happens, VS2015 asks me if I want to reload the modified projects.
If I hit yes, this proceeds to lock up the IDE for a very long time.
Anywhere from 30 seconds to 1 minute I'd say.
Does anyone know of a way to work around this? This is super irritating.
It happens even for the most trivial of changes(modify one project, which only has 1 file in it).
I realize this is a VS problem, and not directly the fault of premake/cmake(or whatever build system you are using), but it totally sucks.
As you said, it's VS related :) But I think you have some problems with your installation : for small projects, reloading the whole solutions should be pretty fast : my personal projects take less than a second to reload (2 to 4 projects per solution, ~100 files per project)
Anyway in the usual course of development, re-generating your projects should not happen that often, except at the very beginning when you need to configure everything.
When you need to add a few files, just add them through Visual Studio : you won't have to run Premake again, and next time you run it, the files will be included by your script anyway. You can do the same with small configuration changes : update your project directly in VS, check that it works, and when it does, upadte the Premake script. You won't have to run Premake then.
I have a large solution with many project. We have about six developers working on this solution using VS2013 and it is source controlled by TFS 2013.
Periodically project references and file references to DLLs are broken. The little yellow sign with the black exclamation point shows next to the reference in the project references and when I look at the properties of the broken references, I noticed that the path was empty for the elements that are broken.
I could remove and re-add the references, but I have done this a few times before and it keeps breaking again.
I Googled around and found several people talking about similar issues, but in most cases I see, after removing and adding the references, everything is ok.
I my case, this keeps happening over and over.
Is there a known cause for this? I can keep re-fixing this, but it's just a workaround and not a solution.
Assuming ProjectFirst generates the DLLs for ProjectSecond, to narrow down the issue, you can first build the ProjectFirst and then build the ProjectSecond to see whether the behavior correct. If that works, you probably need to check your build order.
In Solution Explorer, select a project or select the solution. On the Project menu, choose Project Build Order to check the build order.
On the Dependencies tab, select ProjectSecond from the Project drop-down menu. In the Depends on field, select the check box of ProjectFirst that must build before this project does.
Additionally, check ProjectSecond to see whether it by default to targeting .NET Client Profile. If it is, change it to regular .NET.
We have a solution with hundreds of projects (> 400) and tens of thousands of source files and for some unknown reason a set of updates got applied to the machine right in the middle of a build, killing the build and closing Visual Studio. When VS was reopened some projects did not load (even after close and re-open) so had to sort through > 400 projects and find those that did not load and manually tell VS to reload the missing/not loaded projects. After that things seem back to normal.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
I have a couple of VS 2008 projects (C++) that are linked every time I start a build, even though nothing has changed. i.e. I select "Build Solution", it compiles and links, I select "Build Solution" again, it doesn't compile anything, but links again.
This is quite annoying and I have checked everything that might cause it to link again.
Is there a way to find out why Visual Studio does or skips certain build steps?
Any input is appreciated!
I had some time to revisit the problem and a workmate gave me the tip to use "process monitor" from sysinternals to figure out which file is missing.
Lo and behold it worked! It turns out that Visual Studio insists on linking against a bunch of libs even if the app does not need it. Due to an unfortunate (I guess...) chain of events, one of the default library paths disappeared from Visual Studios global settings, so VS couldn't find this lib anymore ("coredll.lib" in my case).
This didn't affect the final output, because this lib is not needed at all, but it still triggered a relink every time.
There are two possible fixes:
1) Restore the path to this lib in the global Visual Studio settings
2) Use "$(NoInherit)" in AdditionalLibraries to get rid of the unneeded lib.
I used solution #1, because #2 needs to be done for each configuration of each project because can't be done via Property Sheets.
Rebuilding can be caused also by non-existing and unused .h files belonging to the project. Since they are unused, there's no warning nor error about missing files.
Using "Process Monitor" by Sysinternals as mentioned earlier was a great hint towards figuring out the reason.
Bit of a long shot but check the date/time stamp on any dependent DLLs you have. If they are in the future then a rebuild will occur.
Edit: Also have you tried opening the .vcproj files up in an editor to check if anything's unusual? You could also try recreating them from scratch, if that's possible.
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.