This provides very useful information, and allowed me to easily cut my build times by disabling certain unnecessary builds. Having a short edit/build/debug cycle is critical for good developer productivity!
Does exactly what it says in the description. It measures the build times of your entire solution and of the individual projects. This is presented in the output, where you have to select "Build monitor" instead of build. Why this information is not presented by vanilla Visual Studio is just strange. Thanks for sharing!
This is a really cool, really useful plugin. I'm looking to make the fact-based case that we need to greatly reduce the number of projects that we've added to our current solution at work. This plugin is very useful in two ways:
1. MSBuild does not give the total build time for the solution, but this plugin does.
2. This plugin calculates the cumulative time spent building for every build in your current "session," presumably meaning "how long you've had visual studio open." This could make a great argument for investing in speeding up a solution's build times.
I get the following error when installing:
The extension 'Build Monitor' requires a version of the .NET Framework that is not installed.
What version of the .NET framework is required?
I was thinking of implementing something like this myself, but of course for every (good) idea there are others who have already thought of it and have even implemented it. Thank you, dear sir! Is it possible to also make the extension available for VS2010?
Thanks for the kind words.
Well, at first I actually made it for VS2010 and it was just recent that I needed an implementation of VS2012 (due to a upgrade of my developer machine to win8 where 2012 is the only version of VS installed). So I thought if I should support multiple versions of VS and here is how my mind went:
1. Since there is no need to upgrade the solution/project files when opening a VS2010 project in VS2012 I figured that everyone who are using VS2010 today will very soon be using VS2012.
2. I'm not really sure what would be the best way to maintain multiple versions so the easier choice for me is to only support VS2012. (Would be grateful for suggestions in this area)
As it is right now, I feel as if I don't have the time to maintain multiple versions. However if you are interested in contributing I could create a VS2010 branch (since there is an older version commited on Github)?
Daniel, unfortunately it's not the case that all C++ users will upgrade very soon to VS2012/13. Imagine: we switched one big project vrom VS2008 to VS2010 just 2 months ago. I tried to push to go directly to VS2013 but it seemed a too big step because of many dependencies to be recompiled and so on. Anyway, this[*] is a project of mine you can look if you want to evaluate how to support VS2010: tt's a 2xManifests and 2xProjects solution, but the code is all shared. As you already figured, supporting VS2013 and VS201x is a smaller problem. The problem is only VS2010 cause it has a different manifest syntax.
Also, for your interest, VS2010 is here to stay for a long time yet: the end of the extended support is set to be in 14/07/2020. :)
A very important information is missing in your Output as well as in json, i.e. the currently selected Platform and Configuration from Visual Studio (e.g. x64 / Release makes a huge compile time difference to x86 / Debug ).
Not yet, but that sure is the plan to support later on. I was thinking of setting up a simple website where you first of can upload the json-file (and later directly via VS push the data) and view some graphs both of actual data and perhaps of future build-time based on current data.