This is a simple question. I need to get a complete list of the project build order for our solution.
Is there a way to get Visual Studio 2010 to print out a list of the projects in the order it will build them?
Maybe an add-in that will do it?
I'd even settle for a screen shot or series of screen shots except that from the Project Dependencies build order it would take over twenty of them since the dialog is not sizable. What does MS have against sizable dialogs anyway?
Thanks
I'm answering my own just so i can mark it as answered. Thanks to PVitt's comment, i thought of getting a full build output from our CM group and parsing it with regex to get the full list. In 10 minutes i had both the list the projects where started building and also the order in which they finished. Even more than I needed.
Thanks again Stack Overflow.
Even better : reverse the clean solution order. The logs are usually much cleaner on a big project.
Related
I have a solution in VS2013 that has multiple projects, one of which is code from a library which I don't often contribute to but I frequently pull from a repo. I'm looking for a way to show "//TODO" comments in the Task List from only the project I'm currently working on.
As it stands, the task list is inundated with //TODOs that other people are working on. My workaround is to name all of my personal TODOs as //JOB, but even being able to view just one project's //JOBs at a time would be a big plus and would prevent me needing to invent new comment names for each project I have in the solution.
VS2103 doesn't contain this functionally and some people requested this feature in MSDN VS blog.
You can extend VS2013 with Resharper that has a nice ToDo explorer.
Have a look here:
http://www.jetbrains.com/resharper/webhelp80/Reference__Windows__To-do_Explorer.html
You can group your TODOs by namespaces or projects for example...
Let me know if that supports you question.
I am new to TFS. (using TFS 2012 and vs 2008)I may be asking some very basic questions. How to make the TFS build fail when number of warnings is increased compared to the last build? I am willing to write vbscript/perl for it.
Finally I also want track also is there a new warning type compared to the last build?
If some guidance is provided.
Will it better be integrated as postbuild event?
Do i need to create a new Build Quality(in msft jargon)?
Check below article explaining how to do that. It has link to the Xaml file as well.
http://blog.stangroome.com/2011/03/28/fail-a-build-when-the-warning-count-increases/
You might be able to use something similar for your second question about warning type as well.
I am working with a VS2010 solution we have inherited. It has approx 300 projects. Medium term I will try to break this down into multiple solutions, but I can't do that immediately.
One immediate problem is that if I do 2 consecutive builds, the second still does a lot of work, which says to me that something is wrong with the "make" configuration. What is the best way of analysing the build config to determine incorrect dependencies or other problems?
Is there a tool for doing this or shall I try and make my own? Thanks.
(The solution was migrated through VS2005 and VS2008 before getting to VS2010 which probably didn't help the build config)
The 'lot of work' from the second build could be just actions in the PreBuild steps, which are always executed. Make sure you get at least 'normal' instead of 'minimal' build output (Tools->Options->Projects and Solutions->Build and Run). Just looking at the second output should give you the information you need. As far as I know there's no tool to compare to build log files, but it shouldn't be too hard to write it yourself.
We do use TFS to do automatic build and tests with our checkins.
Today we verified old builds we have done last week. We were seeking one specific : 2010/10/27 (5). For some kind of reason it was not showing when we opened TFS/Project/Builds in visual studio (or the build tab in TFS Web).
Here is a screenshot that shows what we saw:
(Bigger screenshot here : http://i55.tinypic.com/35lt1z6.png )
For some reason some builds are jumping, tho I can attest that each builds are iterating and on the 27th there was a 5th build.
Is there something that can prevent TFS from showing complete builds history ?
Did you check the retention policy? It removes builds when there are more then N builds.
Look at the Date Filter drop down at the upper right corner of your screen shot which is currently set for last 7 days.
It may sound obvious, but if you didn't lock the build, then it's also pretty easy to press delete on it (although hopefully the confirmation dialog would save you).
If the build's drop folder is still in your file system, then pretty much all the information on the build is still safe, even if the build has been dropped from your TFS database.
(The only problem I've seen with TFS (2005/2008/2010) is that even if you delete builds, they still show up in the WorkItem user interface so testers have to try to choose the build name from a nearly infinite list - so of course they type something sort-of-like the build number into the field. Sigh)
How can I figure out, how many files needs to be recompiled before I start the build process.
Sometimes I don't remember how many basic header files I changed so a Rebuild All would be better than a simple build. There seams to be no option for this, but IMHO it must be possible (f.e. XCode give me this information).
Update:
My problem is not, that Visual Studio doesn't know what to compile. I need to know how much it will compile so that I can decide if I can make a quick test with my new code or if I should write more code till I start the "expensive" build process. Or if my boss ask "When can I have the new build?" the best answer is not "It is done when it is done!".
It's really helpful when the IDE can say "compile 200 of 589 files" instead of "compile x,y, ..."
Could your version control tell you this? For example in Subversion "Check for modifications" will list everything changed since your last checkin (although not since your last build)
Mind you, doesn't "build" automatically do exactly that? (build only what's changed)?
Usually Visual Studio is good at knowing what needs to be compiled for you.
If you have multiple projects in a solution then just make sure your solution dependencies are set up correctly and it should just work when you hit Build.