I’m now so frustrated with Visual Studio 2008 that I’m starting to consider whether there might be something else that is less broken that could be used for .NET development. What makes me sad is that I really want to like the product, and while there is much to like about it there is even more to dislike. I also want to point out that I don’t think I’m biased against Microsoft or something like that. In fact, I once took an implicit association test that showed I had a mild bias towards Microsoft over open source, so if I don’t like it it must be because I really don’t like it.
I’ve compiled a list of 10 things that I think are horribly broken with Visual Studio 2008, and unlike Letterman I’ll do my list from top to bottom.
- IDE performance
The IDE itself is just unbearably slow, especially when working on web solutions. You’d think that a modern dual-core machine with 4gb ram would be able to open up an ASP.NET page for editing in less than a second, but Visual Studio happily keeps you waiting anywhere from 2 to 10 seconds. And just as you think it’s finally ready for editing the screen flickers while Visual Studio tries to find its inner zen before it releases the cursor to you. Nothing challenging about the solution either (3 projects, ~30 pages, ~100 controls). What happened to usability here? I suspect that somewhere from concept to materialization a tiny “m” was lost in a specification somewhere, causing “acceptable time user is allowed to wait for the IDE” to be 50s instead of 50ms. Seriously, this issue has HUGE productivity implications. And yes, I have installed the hotfix that supposedly fixes a number of performance related issues for web projects. All I can say is: try harder, much harder.
- Web rendering
Rendering of web pages and controls is flat-out broken. Simple pages as well as master pages do render, but as soon as you move into real-life scenarios with nested master pages and control inheritance, everything stops working. You’ll learn to appreciate it when the IDE gives you a small grey box instead a big “unable to render” box. I’ve sometimes gone through the pain of converting user controls to web controls because I was tired of VS not rendering them correctly, but even web controls don’t always render properly (and particularly not so when being used with nested master pages). There was this big thing a decade ago called WYSIWYG that you’d think was still relevant, but I’m probably just being old-fashioned and clinging to old dogmas here.
- Authoring web controls
While we’re on the subject of web controls, remind me that I need to find out who came up with that API so that I can send him some Finnish candy called salmiakki that I hear is particularly nasty. A multitude of base controls, no unified way of creating design time controls for them, and all seriously hard-coded into the ASP.NET pipeline (if you’ve ever considered building your own HttpTextWriter mock for unit testing or design-time rendering, you know what I’m talking about). Hired or fired? FIRED.
- Style sheet handing
This is partly related to the issue above, but important enough to merit a high placement on this list. When editing user controls, the designer is only capable of applying styles if you manually add a <link> tag to the control. Of course, this breaks validation on the pages where the control is used because suddenly you have <link> tags in the middle of pages where they don’t belong. It’s particularly funny that this issue exists at all considering that user controls are notoriously difficult to re-use across projects (due to the separate .ascx files that you need to move around with little help from Visual Studio). If they weren’t designed for sharing, why not just search for appropriate styles in the current project?
There is also the fancy solution of being able to associate style sheets with controls only during design-time. In fact, I went ahead and created a small web control that uses the Control.DesignMode property to dynamically emit a <link> tag only if being rendered in the designer. The only problem is that Visual Studio’s designer doesn’t pick up on this and hence renders the user control without any styles. Doh!
- Build output
I know that redirecting and displaying console output is easy, but I expect more from my graphical applications. Surely someone can come up with a space-saving graphical way of telling me the same thing. And if the compile wasn’t successful, I usually want to go directly to the Task List window anyway. Just promise that you won’t let the guy who designed the original Windows Event Viewer into your design meetings. Or even worse, the guy who redesigned it for Windows Vista so that you can see even less of the interesting bits.
- Web project models
First there were web applications. Then came web sites and web applications were no more. But this displeased the people and then web applications were once again, and now good and evil are forever locked in constant struggle, although that story will have to wait. I’ll go so far as to applaud Microsoft for listening and reintroducing web applications, but why on earth have two different project types in the first place? I can see no technical obstacles to prevent them from being unified as one project type with a few extra configuration settings. To make matters worse, web sites are created using a separate dialog rather than the standard one used for all other project types. Letting some minor project technicality surface into the UI is really messed up if you ask me.
- Edit and continue
I think I’ve tried every possible combination of the relevant settings, and my conclusion is that while this probably works for VB users, it’s nothing but hot air for C# developers. I think I recall being able to edit code in the debugger once without it going berserk afterwards, but then something else stopped working and I had to turn back the setting. It’s been a while so my recollection of the specific problems are a bit hazy, but as I recall it worked somewhat better for web applications than for other project types. I hope you noticed the subtle implied insult above. In case you didn’t, well, you must be a VB user
- “Cross-platform” development
I remember the days when cross-platform meant multiple operating systems, but Microsoft enjoys using it to differentiate between different flavors of Windows. This trend continues with .NET where you can now target many different platforms, as long as they’re based on .NET and thus Windows. But I can understand why they are fearful – OSX just has so much more appeal that Windows Vista, which has been on the brink of being uninstalled ever since it first got there (more on that some other day, perhaps). However, this has all very little to do with my Visual Studio list, but I like opening with a full salvo.
My issue concerns the fact that the .NET system libraries aren’t shared across the various .NET target platforms (CLR, DLR/Silverlight, CF). Now, I can easily understand why this is the case, however, I can’t understand why VS doesn’t abstract away this technicality for me when compiling. I can write code that will compile perfectly regardless of which mscorlib is being referenced, but nonetheless I am forced to make a specific choice. This makes it very cumbersome to write a class library with code that is to be shared between e.g. a Silverlight client and some server project. What I want is the ability to verify that code compiles when linked with certain libraries combined with dynamic late binding for references, so that a class library project can “adapt” to the environment where it is being used. I really don’t want to jump through hoops and loops in order to be able to reuse code anno 2008.
Why does activating the debugger disable half the IDE, turning it into one big, complex modal window that must be responded to? Who says I don’t want to rename or move a file while the debugger is running?
And because this paragraph is really short, can we please have the ribbon UI from Office 2007 in VS too?
- Source code control API
The last entry to make the list is the old SCC API, which to the best of my knowledge still has all the problems of old. If you search the web you’ll find plenty of (SCM) vendors complaining that this or that feature doesn’t work from inside the IDE because of limitations in this API. Source control is and should be for everybody, and to leave this API unmaintained (to the point where the combination of a regular add-in and an explorer plug-in far exceeds it’s capabilities) is just dead wrong.
Ah, it’s done loading my web page, time to get back to some coding…
PS: Original post has been updated to correct minor spelling errors and other late night artifacts.