Reading these posts about the "excellent, bug free" VS development environment: in my experience, this isn't quite the truth.
I've used VS6 since the late 90's, mostly on small projects (less than ~10 000 lines, four or five source files) until 2004, where I signed up to work maintenance on what is essentially a very large codebase (thousands of source files, between 500-50 000 lines per file). In 2006, my frustration with VS6's inability to handle a codebase of this magnitude finally convinced me to try a different IDE toolset. My specific complaints:
- Starting VS6 is slow, and brings the computer to a halt.
- Compiling & linking through the IDE is slow, and brings my computer to a halt. This doesn't happen when run from the commandline, nor, as follows, from a subprocess within Emacs.
- Intellisense stops working a lot; nothing breaks programming flow like having your favorite crutch be unavailable for half the methods (this seems to affect large files more than small). Incidentally, though Emacs has Intellisense type functionality, I much prefer the generic completion available in Emacs/Vim (M-/ in Emacs, Ctrl-N in Vim), as it works within comments and for undefined/undeclared (and unprocessed) structures.
- The method navigation panel fails often, with it listing a method correctly, but displaying "method not found" when selected (the workaround is to select different methods until one is found, then jump around the file for the desired method). I suspect this is related to the parser not handling default arguments correctly in certain cases.
Finally, VS is the only application that has blue-screened my XP machine (this happened only twice, however, and wasn't involved in my decision to migrate to a different toolset).
Regarding software, either you bend software to meet your needs, or it bends you to meet its limitations. Unfortunately, because VS has a high difficulty regarding the former, I found I was consistently having to integrate workarounds into my day to day coding practices.
Visual Studio 6 is a full three versions behind the current version ( VS 2008). I use Visual Studio 8 and have none of these problems. Complaining about a version of VS that came out 10 years ago is ridiculous.
I can't imagine how building is freezing your computer when using the command-line isn't; all VS does is call cl, link and mt in that order, you can procmon it and watch it happen. The Intellisense thing, on the other hand, is the most ridiculous thing I've ever seen - the official Microsoft solution is to delete the Intellisense database and restart VS, apparently it "gets corrupted over time" and they don't feel the need to look into it
It's specifically at two points of the build--firstly, when VS6 is starting the compile (and trying to find modified files, I suppose), and during the link step.
I think the IDE is doing something with the toolchain to give it an incredibly high priority (and therefore build faster). The only evidence I have for that is a) command-line compiles take longer than they do through the IDE (using msdev to process the dsp file, not using nmake/cl/link), and b) windows messages (e.g. Send/PostEvent) don't seem to be processed during the link stage.
Regarding the Intellisense bit, you've reminded me of our "process" used to fix VS when it stops compiling files correctly: try deleting all our non-source controlled files (which includes the VS specific databases for things like classwizard, object files, etc) and see if that fixes things. If not, then restart.
You are comparing VS6 to something current, which is not fair. Lots of these hitches you've had (which I don't doubt, since I've been forced to deal with some old VB6 projects) has been fixed long time ago.
I'm not saying Visual Studio 2008 is flawless, perfect or the second coming of Christ(tm), but in general I've had very few issues with it.
Whether it's fair or not, I can only knowledgeably critique what I
know. However, I've heard (and propogated) this basic comment
describing the robust solid development experience that is Visual
Studio for more years than VS.NET (or, obviously, 2008) has been
around.
(Not that VS6 is terrible--I still think it's a serviceable IDE for
small to medium sized projects. However, it doesn't scale well to our
large projects, and, personally, I've found that IDEs in general
foster a lazy attitude towards improving personal workflow)
I've used VS6 since the late 90's, mostly on small projects (less than ~10 000 lines, four or five source files) until 2004, where I signed up to work maintenance on what is essentially a very large codebase (thousands of source files, between 500-50 000 lines per file). In 2006, my frustration with VS6's inability to handle a codebase of this magnitude finally convinced me to try a different IDE toolset. My specific complaints:
- Starting VS6 is slow, and brings the computer to a halt.
- Compiling & linking through the IDE is slow, and brings my computer to a halt. This doesn't happen when run from the commandline, nor, as follows, from a subprocess within Emacs.
- Intellisense stops working a lot; nothing breaks programming flow like having your favorite crutch be unavailable for half the methods (this seems to affect large files more than small). Incidentally, though Emacs has Intellisense type functionality, I much prefer the generic completion available in Emacs/Vim (M-/ in Emacs, Ctrl-N in Vim), as it works within comments and for undefined/undeclared (and unprocessed) structures.
- The method navigation panel fails often, with it listing a method correctly, but displaying "method not found" when selected (the workaround is to select different methods until one is found, then jump around the file for the desired method). I suspect this is related to the parser not handling default arguments correctly in certain cases.
Finally, VS is the only application that has blue-screened my XP machine (this happened only twice, however, and wasn't involved in my decision to migrate to a different toolset).
Regarding software, either you bend software to meet your needs, or it bends you to meet its limitations. Unfortunately, because VS has a high difficulty regarding the former, I found I was consistently having to integrate workarounds into my day to day coding practices.