Like Compact Frameworks the ASP.NET designer is "build your own"

Now that Danny has explained, with
this
post
the real story behind Borland‘s Delphi.NET Compact
Framework (CF)
support I’ll throw my hat into the ring regarding the ASP.NET designer
support.  Basically, it’s the exact same story as CF in that it doesn’t exist
outside of VS.NET and if you want an ASP.NET designer you’ll need to write it
from scratch.  Well we’ve done exactly that with Delphi.NET and C#Builder, in
other words we implemented Danny’s option number 3 (refer to the link to Danny’s
post above).  As Danny mentioned this is the most flexible option but, as he
said, it does come at a high cost.

As ASP.NET 2.0 takes shape, in some ways, we’ve been in a bit of a holding
pattern watching and studying the level of support that the new designer
provides.  Had there been designer support in the framework that we could have
leveraged perhaps we’d have been able to spend our time working on additional
supporting features rather than cautiously planning and implementing just the
features we feel will truly make it into the final release.  Additionally, Microsoft has all but removed .NET 1.1 designer compatibility
from .NET 2.0 by not only deprecating old methods but at the same time making
them  stubs so they don’t even do what they used to do; two steps forward and
one giant step back.  I agree with Danny when he says that he doesn’t think all
this occurred because malious intent on Microsoft’s behalf but I think third
parties like Borland could argue that it’s perhaps not the best way to get
other’s to support your framework which we’re really working hard to do.

Let’s imagine for a second that the ASP.NET and CF designers had been
implemented like the WinForms designer.  Had that been the case I think it would
be reasonable to assume that third parties could have spent their time finding
ways to make developing for the .NET Framework that much more compelling rather
than reinventing an already existing wheel.

I suppose it’s necessary to ponder the reasons why Microsoft decided to leave
these two key designers out of the framework?  Danny already discussed the case
for the CF framework so I’ll take on the ASP.NET case.  This is an interesting
situation because Microsoft has actually implemented two ASP.NET designers
themselves: VS.NET and Web
Matrix
.   Why is that Web Matrix was developed within the ASP.NET team
separate from VS.NET?  Did the ASP.NET team not like the implementation of the
VS.NET designer?  Was it too different from the way previous versions of ASP
worked (code behind vs. inline)?  Was this a way for the framework guys to
“twist the arm“ of the VS.NET guys into implementing certain features wanted by
producing a competing (ok, perhaps that’s a stretch) free product?  Or are these
arguments conspiracy related and did the ASP.NET guys just want a free tool to
further their platform?  Perhaps we only have to look as far as VS.NET 2005
which includes support for inline pages and the VS Express versions which are
free.  Considering that Web Matrix has staggnated with the “reloaded“ version
and the last “call for feedback“ on Web Matrix was made in 2002 I sort of doubt
we’re going to see another update of Web Matrix any time soon.  Ok, so maybe the
ASP.NET and VS.NET guys have worked out their differences (if there were
any).  It will be interesting to see what happens to Web Matrix when the .NET
2.0 framework hits the streets.  Will Microsoft still prominently display Web
Matrix on www.asp.net when it’s woefully out of
date?

There are also the questions of designer implementation.  In VS.NET, prior to
2005, the ASP.NET designer was based on the MSHTML
control which had some obvious pluses but some considerable minuses as well, for
example, the the well known formatting issues (which btw, Microsoft
recently stated at VS Live took 3 developers 18 months to solve).  In VS.NET
2005 use of (at least the publicly available version and no I have no idea if
they are using an internal version of MSHTML or perhaps the Front Page designer
or even a completely new designer) of the MSHTML control is no longer part of
the designer.  In light of the recent IE7
announcement
 I wonder if any of the MSHTML editing issues will be addressed
since they may not be important now their own designer has parted ways?

There is also the argument that if the WinForms designer had never been
released all this would be moot.  Right?  That’s hard to say but it wouldn’t
be hard to believe other vendors would have joined the party if these other
designers were available today.  Take SharpDevelop for example, without the
WinForms designer it might have been little more than a code editor/debugger
then again, maybe not, but the forms designer does make it a lot more
appealling.

Where to from here?

Fortunately, since Borland has already made the “more expensive“ decision
regarding the ASP.NET designer it will be less work for us to move to 2.0 than
it would have been otherwise.  In fact, we’ve already made some good progress. 
Additionally, since we own the designer we’ve had the ability to extend it with
things like the Tag Editor and in the 2.0 timeframe we’ll have the same
opportunity.  Hopefully, we won’t have to make the “more expensive“ decision
regarding some of these other designers.

In the long run, perhaps it will boil down to whether or not Microsoft
is interested in an active third party tools market with companies really
extending the reach of the platform rather than reinventing the various
designers required to even play in the same sandbox.  Just as Firefox has pushed
Microsoft to update its admittedly lagging web browser, competition in the tools
space can equally push Microsoft’s own tools and thus their platform, which in
the end is their real win.  Let’s hope some of the people responsible for
the WinForms designer decisions can influence some of these other critical areas
of the .NET world within Microsoft.  Avalon anyone?