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.
Jesse Houwing
shared this idea
12 comments
-
Daver
commented
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.
When you think about it, unless we are code generating with T4, the code is pretty much static. Only the code we are modifying should actually be changing. While I'm making modifications to code, perhaps Visual Studio can utilize those extra CPU cores to background compile C#, or index the contents of the HTML DOM, or preparse the javascript, etc. Or maybe the changes I made should be recompiled. Just my 3 cents. -
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. -
Philippe
commented
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.
-
ChrisTorng
commented
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.
-
jeffpierson
commented
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.
-
Anonymous
commented
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.
-
drweb86
commented
Also could you build during modifications of files silently.
-
drweb86
commented
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.
-
Dave
commented
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.
