My wish-list for the next Visual Studio.NET / .NET api release, part II

I've blogged before about wishes I had for the IDE I use on a daily basis: Visual Studio.NET (currently v2003). Since that blog I've made a new list of new wishes not mentioned in the previous wish-list. I've also included wishes for .NET and the .NET API. The list is very long so I decided to post it as a story. You can find the story by clicking here. Below is the list of items I discuss.


  • Generation of a makefile (C#, VB.NET)
  • The ability to define post-build steps which call plug-ins.
  • Cache the Help Index list between coding sessions.
  • Visual Studio.NET should contain a lot more wizards and helpers for real applications.
  • Expose a better object model for macros.
  • A callers / callees graph would be nice.
  • Appdomain instance reference viewer.

C# Editor

  • Give Tooltip intellisense a better brain.
  • Coding helpers should be smarter.

.NET Controls

  • Replace the winforms datagrid.
  • Replace the winforms treeview.
  • ListView: sorting means sort it, not fake it.


  • Make all classes unsealed.
  • Make more classes serializable.
  • More classes should have abstract methods and virtual methods.
  • Implement more base classes.
  • Pay more attention when designing namespaces.
  • Add an API to work with XML the OO way.
  • If serialization to disk succeeds, deserialization should succeed too.
  • Make event handlers / delegate definitions maskable with [Nonserialized].


  • An easy way to get a reference of an object in the current appdomain.
  • Where are the monikers?
  • Make assembly code unloadable from an appdomain.
Click here for the complete article.


  • Here's a couple I'd like to add to the .NET API:

    1. More interfaces. Not enough classes derive from interfaces, which makes interface-based testing (read test-driven development) almost impossible. (Think HttpContext.)

    2. Better abstraction in ADO.NET. You can't really write clean generic data access code because you can't create a DataAdapter without knowing whether you're doing SQL or OLEDB.

    Those two have bugged me for a while.

  • ::Better abstraction in ADO.NET.

    Worse - when you use visual deisgn (drag drop them onto a form) you get all the stuff hardcoded. Terrible.

    I know you should never code this way, but they DO support it - and they do so wrong.

Comments have been disabled for this content.