Reduce overall build time and provide better feedback on the progress in the UI.
Building currently completely blocks the UI, and no progress is shown. Just showing a responsive, non-blocking UI windows which shows progress and has a working cancel button would be a great addition.
Pressing Ctrl+Break is unresponsive. I must repeatedly press this combination hoping that Visual Studio will ack at some point; typically, it doesn't. I have builds that take minutes to complete and I cannot cancel them. Being able to cancel them quickly so that I can make a quick change and then rebuild is imperative.
When linking our C++ based .exe the link time can take up to 5 minutes and only uses one CPU core. Please parallelize this and distribute across multiple cores.
Especially relevant for header-only C++ template libraries and other large code bases that trigger compilation cascades -- at least alleviating this problem would be a big win!
At work, our VS solutions are now fairly large. It seems to take forever for me to load a VS Solution. Can't we load all the files, let me open a file and edit, and then let VS do what it needs in the background?
When I press F5, I really want the website to be running ASAP. If possible, I'd like to see it up instantly. I have lot of ideas I want to try when debugging and I forget them when I have to wait a long time.
Rudi Larno commented
I have been using CodeMaid to better visualize the Build Process. It makes perfect sense to me.
That was before I started using NCrunch wich is able to do continuous builds of the code -- while I am typing the code. On numerous occasions, NCrunch has shown me compile errros long before VS has been able to detect them. However I also still suffer from Ctrl-Shift-B, using is unintentionally most of the time, it has become a second habit next to pressing Ctrl-Shift-S, that I sometime do it unintentionally. This has left me looking at some compile error (more exactly the squiggly lines) wondering what the problem is. Why would it not compile, changing the code over and over; only to discover that the code DOES compile (as NCrunch is happily doing so and I've got all green). And then to remember that Visual Studio is actually behind, and I need to do a Build to have VS be up to date with the code.
Well if it was possible to continue editing code while the compilation is in progress, it would be much less of an issue.
A nice option would be to be able to compile projects on which the current file depends on so that we won't have to wait for the whole build if we need changes to be be built up to the current project (included or not) so that Intellisence and designer would pick latest changes.
As mentionned by "Just Me", compilation of C++ code should really be improved. It does not make sense that it can be more than 10 times slower that equivalent C# code.
And by the way, Intellisence should be able to pick changes made in C++ code from a C# project without rebuilding the DLL. That alone would reduce the need to explicitly build dependant projects.
Smart configurable background compilation might be the answer. Thus when we would want to run a program almost everything would already have been updated.
I would like the progress showing on taskbar button. That let me start the build, go to other program to do something, seeing the progress on taskbar button has done, then go back to IDE, or refresh the modified web page on IE.
Aaron Lawrence commented
@John: I don't think that's related to the UI responsiveness during building.
This is already been improved for Visual Studio 11. I saw it in a video preview and builds no longer block the UI and thus can be stopped easier mid build and such.
I'm going to un-vote my own suggestions as I missed this one:
So, go vote for that since it's got more votes already.
Also could you build during modifications of files silently.
Could you please borrow some ideas from Jetbrains resharper experimental build features for c# code ?
Just Me commented
For C++ builds, I'd really love to see some out-of-the-box thinking here. We're still compiling C/C++ code the way it was done in the 70's. It doesn't scale. Headers get parsed dozens and dozens of times, thousands of files are touched in order to build a single translation unit, the linker becomes a non-parallelizable bottleneck, and it's just painfully slow. Pre-parse all headers, compile them in isolation (where possible, which is 90% of the time) and insert them into the TU's parse tree, maybe even rethink the rigid translation unit separation. Maybe a Dynamic Programming algorithm could work, build a tree bottom-up of the included headers, and for each level in the tree merge them together -- and do that once, and reuse the results across TU's. As long as the resulting code is the same, you don't *have* to structure the compilation process this way. ask yourselves how C++ should be compiled in 2011.
For me, this applies to having multiple C# projects in the same solution. It's especially slow when each project targets a different platform; e.g., Client Profile, Silverlight 4 and Windows Phone 7.
Matt Varblow commented
Our C# application (very large, many solutions) also builds very slowly (several minutes). We'd love to see this improve.