When the reasons for cutting an ASP.NET feature are not credible...

Note: this entry has moved.

For quite some time now, I've been trying to raise developer's (and MS) awareness of how an unbelievable bad idea it is to remove an amazing feature in ASP.NET v1.x and replace it with a bad, already tried and failed one in v2. Even given the overwhelming feedback (151 voters with an average of 4.7 over 5), Microsoft decided not to fix it, but they gave the wrong reasons for it.

The main reason was that "the existing model in VS 2003 was prone to bugs and code-loss and as such we've removed the functionality of a designer tray for components defined in InitializeComponent.". I reopened the bug and added:

"The Windows Forms designer keeps supporting the Component Tray just as it used to, so I think they somehow solved the "prone to bugs and code-loss" nature in it, right?

I can't see how given that it's working on WinForms, you can't take advantage of it. It's a very important feature to be able to develop components that are reusable across view technologies. This is the last time I'll reopen the bug. I just want an answer and if you're planing to put it back as it was (that is, 100% compatible with the WinForms support and codegen features) or if you're going to break the model anyway."

I'll keep bothering these guys until they give us component developers a satisfactory answer. If you agree, you should definitely make your voice loud and clear.

1 Comment

  • One big difference between Windows Forms and ASP.NET is that Windows forms are still relying exclusively on code to instantiate and lay out the controls on the form, whereas the ASP.NET model is essentially declarative (even though you may use the programmatic model if you want). ASP.NET is actually closer to Avalon than it is to Windows Forms.

    There are huge differences between both designers, but the fact that the web designer now /never/ touches your code-behind (except to create event handlers) is a big one. Nikhil explains very well why data sources are controls and why arbitrary components (and not only controls) could regain their place on the design surface. V-next, unfortunately.

Comments have been disabled for this content.