In years gone by, Microsoft would release upgrades to Visual Studio every six months or so. Many, bug fixes and small changes were made. In recent years we've been made to wait for major releases to get the small fixes we need to make our lives easier everyday. We all understand why Whidbey has been delayed, but what is stopping Microsoft issuing an Service Pack for VS .NET 2003. One that doesn't require any framework (or CLR changes). Just IDE fixes:
Here are the list of issues I would like to see fixed (in no particular order):
1) The winforms designer has a lot of problems when developer's on a team work at different screen resolutions. Half our team is over the age of 25 and needs to work at 120 dpi. The other half prefers 96 dpi. When I design a dialog (at 125 dpi), that conforms to Windows Common UI guidelines, it looks cramped when someone else tries to edit it 96 dpi. Please save my eyes. Fix the designer so that it works.
2) Bake support for the Windows Common UI guidelines (or its successor) in the designer. Its annoying to have work out exactly how tall the buttons, labels and text areas should be. I get frustrated having to the math for each control in dialog. At the
minimum give us some extra toolbar buttons at the top "Apply standard space between buttons" etc. *** Anything that saves the painful 15-20 minutes per dialog would be welcome ****
3) Test VS .NET using large projects that have deep hierarchies (both namespace and on disk). There are number of features that become difficult to use. The worst is "Find in Files", I've setup a number of customized directory lists to make my searches more specific. Unfortunately our directory structure is deep enough that I can't distinguish them in the pull down list.
4) Find within a file dialog (ie just Ctrl+F) - sometimes I'm searching on something that occurs many times in one file. It would be nice if instead of visiting everyone, I could just get a list like the "Find in Files" dialog.
5) The IDE always categorizes things by assembly first in the Class or Solution Explorer views. This is annoying because often times, the physical packaging is less important than the namespace hierarchy. A 'logical' view where the assemblies are not shown would be a big help-- just organize things into namespaces.
6) Evaluation of properties in the debugger is currently an all or nothing setting. While I often need to be able to evaluate a property, I would like to control when it is done. Reasoning: We always implement our properties with Asserts to check against illegal status (null, less than zero, etc.) If the properties are evaluated in the constructor before they are set, I get nailed with the Asserts. A good solution would be to create an "Evaluate/Modify" item in the debugger's context menu.
7) More flexible run configurations. For some reason, when you specify a different start application or command line, that information doesn't get saved in the shared project file, only the local .user one. It needs to be shared in the main project file so configurations can be shared across a team. An example might be having a DLL assembly with test cases, and specifying NUnit as the exe to run.
8) Multipane class explorer. Many Java IDE's (JBuilder, Eclipse) have a pane for selecting a class, and another pane that shows the class members. This is a much better way to explore classes then the VSNET class view, which put members and classes into one gigantic tree; there are just too many levels of hierarchy there and you're constantly scrolling horizontally or collapsing/expanding nodes. In addition the JBuilder class view tracks the currently displayed file.
9) Debugger start-up time. The debugger takes a fairly long time to start-up. I've read all the FAQ's on this and don't believe its system configuration.
10) More flexibility in file arrangement. The IDE assigns a namespace to resources relative to the project file. This should be overridable so you can put resources anywhere.
11) Flexibility in build output directories. You can assign any old directory for build output, but the intermediate files still get placed in an 'obj' directory relative to the project file. This is annoying since often times you want all build output to go to a single directory that can be nuked to ensure a completely clean build-- the intermediate files should go in the same place the final assembly gets built.
10) Code formatting. The IDE doesn't really do full blown pretty printing of code, it will only rearrange your indentation/braces with a Ctrl+K+F. It would nice to have a real formatter like the JRefactory plug-in for JBuilder. This would also arrange whitespace, Doc comments, add file comment headers etc. This is really the thing I miss most from JBuilder. This would be configurable via an XML file. This would also be easily extensible so that we could additional formatting options later.
11) Printing support. The IDE should offer 2-up printing in the Page Setup dialog. This is useful when printing out code for peer review.
12) Resizable dialogs. Another thing I miss from Java IDE's-dialogs are usually resizable. I understand a large portion of the IDE is still written in MFC, but if it could be migrated to WinForm resizable dialogs that would great.
13) Refactoring support. Ability to rename classes, methods, push up/down, extract method etc. All the good extreme programming stuff. And make sure it works well with the source control system. Recent versions of JBuilder and Eclipse has decent refactoring support.
14) Improved window management. When a number of files are open it is difficult to distinguish between them because the file tabs stick an ellipsis in the middle so you labels like 'Foobar...\...leDialog.cs'. The tabs should show the filename without the path if not enough space is shown since filenames are usually unique. Also a 'back' or 'previous file' button/accelerator would be nice, just like the jump button on a remote control. The best solution would a dockable pane that has list of all the currently open windows (effectively a replacement for the windows dialog). By default the pane would only display only the filenames (without the path).
15) Floating document window just like the dockable panes can be floated. On two monitor systems it is very nice to able to drag a source window to another screen for comparison to source on the primary screen.
16) Enhance Doc comment support. It would be nice to have the IDE automatically format the Doc comments for display. In the IntelliJ Java IDE, it will do this on the fly and show the formatted comments in a popup window... very nice. Of course we'd want it to work for all languages in VSNET. ;-)
17) In the Exceptions settings dialog, a single button to reset all exceptions to their default state. Reason: It is annonyning enough to have drill down 2 levels of exceptions to set them, even more annoying to try and remember which exceptions are currently trapped and reset them all.
18) The ordering of compilation errors in the task list is often different from the order in the output window. As a result if there is a compilation error in one assembly the follow errors in other assemblies get placed ahead of it.
19) Make internals visible to 'friend' assemblies - making it possible to unit test internals without reflection or making them public.
In the longer term (Whidbey and beyond):
1) Dynamic reloading of modified classes during a debugging session. Aka Edit and Continue - for C#. It would speed up some of my unit testing sessions.
2) Ensure that Whidbey, can develop applications for deployment against 1.1 (and 1.0) frameworks. Those of us developing smart client (no touch deployment) applications will have to live with whatever is deployed on our end-user's machines for years to come.
Finally, its time to create an open bug database (like Sun's for Java), that developers can access and track progress of bugs. There is nothing more annoying than discussing problems with people at MS, have the problems acknowledged and then hear nothing for 2 years. I shouldn't have to find out that favorite problems are being addressed by installing the release or reading a PM's blog.
This one change alone, would go a along way to improving my perception of MS's reactiveness to its developer's needs.