ASP.NET Simplicity -- When Is Too Much Simplicity a Bad Thing

I'm a big fan of simplicity -- but some of the things the MS ASP.NET team is doing in the name of simplicity are adding complexity -- and some don't even have realistic workarounds.  I started thinking about this post while writing my last one about multiple server forms, but there are other examples where MS is making things harder in the name of simplicity.

1.  A big cause of grief going around right now is the impact on real enterprise developers of the decision to have web projects not have project files.  Yes, this was a decision made in the name of simplicity -- and for 99% of the web developers out there that ASP.NET targets it probably was a very good decision.  But once again the problem is that this simplicity is being forced on the rest of us, and many of us enterprise developers really need many of the capabilities the project file gave us.  Should MS have known better -- most definitely yes -- I for one tried to warn them about this very issue at the first Whidbey preview in October of 2002, and I think I was probably the one attendee that best represented real enterprise developers as opposed to authors and trainers.

2.  Another "problem" that was introduced with ASP.NET v1 and is now getting worse is that MS gives us "rich" web controls with properties like backcolor, font, and width.  Unfortunately, there are no such html attributes -- everyone of these properties is instead actually part of the html element's style.  Yes I realize this simplifies things greatly for newbies, but all its done is "teach" more people that CSs isn't important -- and its made real CSS stylesheets much more troublesome to use in ASP.NET.  Think I'm off my rocker?  Did you know that the Calendar's Title CssClass did not work at all in v1 since no one ever bothered to test stylesheets adequately?  Want another example?  Did you know that WebPartZones, yes that new wonderful portal technology in ASP.NET v2, will not work with the CssClass properties -- and according to MS that's "by design" and "postponed"?  I was really hoping to use WebParts, but all I had to do was try to use it with CSS stylesheets (don't most portals work that way) and I realize they are pretty much worthless -- not to mention take a look at the ugly html they produce.  And what's the work-around for this you ask -- Themes and Skins.  I know that Themes and Skins are one of the cool new features of ASP.NET v2, but have you ever stopped to think that they wouldn't be needed if we just used CSS stylesheets!

3.  My last example is harder to explain -- its not really an issue with "postbacks" so much as a problem with the way most controls handle the postback to determine what to actually do.  I'll use the ever popular ASP.NET Forums as an example -- specifically the moderator tools to approve a post or unmoderate a user.  I'm looking at a post right now where the Approve link-button has the following link: javascript:__doPostBack('ContentControl$_ctl0$PostRepeater$_ctl0$_ctl0$_ctl0$Approve','').  So what's the problem?  This is all based on the relative position of controls, and the data they are assumed to contain, instead of using the actual data key.  Sure you can make an argument that its more secure to not expose the data key, but the problem is that without it there is no good way to reliably know what data we're supposed to be talking about!  If you use viewstate to move all the data with the postback then its not a problem -- but of course we all hopefully know that moving all of the data in viewstate (the default though in most cases in ASP.NET) is not a good thing.  So instead the data is re-queried on postback to determine what data goes with which control, and therefore what post should be approved in this case.  But the data can and does change on a real website with lots of activity (hmmm, like the ASP.NET Forums)!  So what ends up happening is that the wrong posts are often approved and/or the wrong users are often unmoderated (or we just don't bother to unmoderate anyone).

Now to their credit, they have fixed a lot of these issues in the ASP.NET Forums over the years -- the delete post link now uses the actual key for instance -- but many of these very real bugs persist.  The standard method of not using the key is also not very performant, since even if you forget the case of data changing you still have to re-query the database just to do something (and then query it again to get the final set of data to display after the change) -- unless of course you put all the data in viewstate.  Note that I do not want to imply that postbacks, viewstate, controls, or any other feature is inherently wrong -- I only want to point out that the simplification has went too far and can actually affect data integrity and/or performance if you use a lot of the defaults.  For me this means that I never use the datagrid for more than the simplest of pages or prototypes (if even then) -- and that's really not even a burden once you've used the repeater a few times, or written your own "grid".  But the problem persists (and most people don't even realize it) -- and just as bad there are now thousands of articles out there to help you figure out how to get around all the various short-comings of these simple controls.  Why?  Because this simplicity is great when it works, but unfortunately its teaching many web developers to never do anything else -- I can't even begin to count the number of "huhs" I get when I respond to questions about the datagrid that I don't know because I don't use it.

OK, end of post -- I hope I didn't lose everyone -- or make you think I've lost it.  I really do love ASP.NET, and I do appreciate the folks on the MS ASP.NET team, and I do understand the needs for some of this simplicity so that they can reach out to a much wider pool of web developers -- I do not want their job.  I just think that sometimes what is simple in the short-term or small cases ends up being anything but simple in the long-term or bigger cases -- so there needs to be a better balance in some cases to not make things too easy just because someone wants it that way.  I encounter the same types of things even with my ORMapper -- why can't you just do this thing that would make my code go from 3 lines to 1 line, even though it will make other situations far worse -- that's not simplicity to me.


  • I totally agree. I absolutely hate quoting him, but a lot of this is the "law of leaky abstraction".

  • I am an ASP.NET enterprise developer, have been for the last 4 years or so, and I have no problem with the lack of project files. In fact, I like it. Websites are a different beast and by trying to mold them into the standard project idea alot of mistakes were made. Sure you could "exclude" files from a project, but chances are half the time they still got deployed. Not only is that not the expected behavior, but it could be a security risk. What can't you do with the new model? (truthfully they should have done both, but still curious what you specifically don't like about the new model)

    Agree 100% on the CSS and postback issue.

  • I don't see what the problem is. You are always free to write your own custom control library with your custom post-back handling scheme. You can always use AJAX.Net if you want to bypass post-back alltogether. If you don't like the way MS handles CssClass, simply inherit the control and override the way it renders. What's the big fuss? You have to write a little bit of extra code? Well, do it and put it into an open source project so everyone can reuse it. I just don't get it. If it sucks, don't use it (controls).

  • Thanks for this post. All of these things really really bug me about ASP.NET, particularly the stuff about style properties in code. I wish the framework forced new developers to use best practices instead of encouraging sloppiness like compiling colour properties. I'm really disappointed they didn't get the Web Part stuff right - I've dealt with the Sharepoint web parts and the tag soup they produce and was really hoping they would spend the time to get it right in 2.0.

    I was at an MS Developers conference in Las Vegas last year and at the keynote, they mentioned xhtml support in 2.0. They asked the audience who was excited about this, and I was one of maybe 5 people in 200 who put up their hand.

  • IMO, regarding web projects, they should keep the traditional approach for Visual Studio, and apply the new model only to the Express versions.

    The Express versions of VS are really for different users, and so I can understand they work differently in the name of simplicity.

  • I'm with Paul in many respects.

    It feels as though much of the ASP.NET Framework has been built to make life easier, but generally, it's only easier for the people out there who are not real developers.

    The hype about 70% less oce, great, but in practice, as soon as you need to do anything off the beaten path you have to break out the books and write the code.

  • Just to be clear, the current version of the moderation tool does not suffer from this issue despite using the postback model. The control that renders the moderation menu was rewritten for the latest version on and does not have an issue with control placement (even though it continues to use the postback model).

  • Yeah, once again another agreement here.

    The projects can be got round by creating class library projects and setting various properties and tweaking the VS install, documented elsewhere. I'm not sure how the commenter who claims to be an Enterprise dev said it's not a problem for him, perhaps he doesn't have source control or staging servers.

    As for the ASP web controls, I gave up with them long ago and use the Generic Html controls and in doing so got rid of the postback data too. My main reason at the time was not just the poor styling without CSS but also the lack of XHTML compliance and dubious downgrading to other browsers. By switching to the System.Web.UI.HtmlControls stuff I can do pretty much what I like. Sure you loose the database stuff but I'm normally dealing with objects anyway and you can re-populate fields and current settings in Page Prerender along with the localisation code.


  • One of the solutions to this issue floating around the blogosphere is to use class library projects. If you use class library projects, can you get design support for the ASP.NET 2.0 MasterPages?

  • Alex is correct -- I was mistaken in fact, but not principle. :) Some of the links now include the keys, and some do not so I poorly assumed the problem continued. Anyhow, I just checked, and Alex is correct -- because the data is now in ViewState ! And that's why I say I'm not wrong in principle, since I didn't expect to see the data in viewstate. I guess the fact that its the moderation page makes it less of a problem, but its still a work-around to some less-than-optimal default solution.

  • Like I said before, I think they should have done both methods, but truthfully most of the "bugs" people talk about are not major things and are more a shift in mentality than anything.

    The guy with the file reference doesnt understand how references currently work in VS. No enterprise developer I know would add a reference to a file in some arbitrary place on his system, it should be copied local or to a general share used by everyone. Its a shift in method, but I dont see it as a huge deal.

    Not being able to create a reference to a web project doesnt seem like a huge deal to me either, if you have functionality in there that you want other assemblies to use chances are that functionality should be in a class library and not your web project. (You could still pre-compile the project for code-gen type of stuff if you wanted)

    The loss of pre and post build events is a bummer, I was hoping they would create a workaround for that perhaps through the solution file.

    There will be issues with any change like this, but I think there are benefits as well. A web site is now treated like a web site as opposed to having a project that may or may not be a fair representation of what you want to deploy.


  • A month or so ago, Betrand Leroy blogged about the AJAX.Net vs Client Callback differences, and said something that really stood out

    "I think the main reason for this difference in the expectations and what we delivered is that we tend to think as control developers, whereas most of our users think as application or page developers."

    I've often wondered how broad the implications of that statement were (and wtf they were doing to correct it).

  • Do not forget to vote and comment on the bug forms in the MSDN Feedback Center to let Microsoft know what you think about the new problems. If you don't, there is no chance they get fixed.

  • Lack of project files is a drag - I feel like functionality has been taken away from me to accomodate junior developers.

    Frankly, I consider most Click-n-Drool stuff in Visual Studio to be detrimental. It's really great for WebForms and WinForms GUI development, but I worry when I see a project where a developer has dragged a PerformanceCounter object, or a 'SQLConnection1' object onto a WinForm, I know that we are in for trouble.

    It looks great in a demo, but generates code like: this.sqlConnection1.ConnectionString = "workstation id=\"DENNANY-J1-2K3\";packet size=4096;integrated security=SSPI;data so" +

    "urce=\"(local)\";persist security info=False;initial catalog=Northwind";

    What a mess.

  • I would like also to add that very few professional writers or speakers are really talking about the conversion. Most of the resources you find on the web are about new cool stuff in ASP.Net 2.0 but not really about how to make my .Net 1.1 moving to the next level. I don't even know one article talking about .Net 2.0 and SQL 2000! All are written using SQL 2005 and in many cases by Windows developers. And in real world development my bets are that 90% of enterprises will keep their current SQL software untouched for the next 6 months! And as you say Paul ASP.Net 2.0 is too complex as it is. The learning curve is very steep and I don't really know how many months it will take to be at ease with the new framework.

  • Talking about complexity, I am really concern also by the return of the spaghetti code. We are all preaching since ASP died to separate HTML from code and now Microsoft is doing a huge step backward (For exanple the declaration of connection string in the front-end ?!?). Of course I heard the argument that this will help the beginners but how if they don't know the good practices from the beginning?.

  • And for the record, I agree completely with you in principle. =)

  • James> I was hoping they would create a workaround...

    We don't need no stinkin' workarounds.

    This is how it looks today: a lot of features have been removed, and MS is trying to put them back under pressure as workarounds.

    I think there was no need to change the model in the first place and lose so many features.

    A web project may be a specific kind of project, but a project nonetheless. Which means web projects should offer the same support other projects do.

  • I'll agree on your second point. On the third, I think you're placing the responsibility in the wrong place. If you want to pass in the right data for the postback, do so with the CommandArgument and CommandName. That's not Microsoft's fault.

    And on your first point, well, I'd like to think I'm an "enterprise developer," and I've not run into any issues yet from having a folder-based project.

  • I agree with Pauls original statements. I think there's a ton more in ASP.NET 2.0 and Visual Studio that follows this same model - provide some high visibility feature, make it easy to work for demos, then leave out some key features that people really need once they build real applications. Lots of stuff in 2.0 like this. Localization and Resources is another that absolutely blows me away. The Pre-Compiler which has made deployment an absolute mess. Script Callbacks with its minimalist approach. The list goes on and on. Sure there's lots of good stuff too, but so many of the features just fall short of being truly usable in day to day development that you won't be able to actually utilize them in your apps and create your own.

    Oh and Charles - yeah, you can write your own, but the folks at Microsoft should be good enough to know their customers to know what's needed. The ASP.NET team's been pretty arrogant about how they position ASP.NET 2.0 as faster, better, cleaner, easier etc. when in fact this may turn out to be a big myth... Workarounds are OK for a product that has matured. Workarounds for a product that haven't even shipped is pathetic especially if you go to Feedback center and review many suggestions and Microsoft themselves posts solutions as 'workarounds'. That's a pretty sad state of affairs...

  • Paul,

    I agree with you on most of this. In your first point, however, I disagree that the project-less nature of ASP.NET is not a problem for 99% of developers. In my opinion, it is a problem for many devs.

    One thing I loved about getting into .NET from the ASP.old world is the fact that it made web app development much closer to smart client development. Now it seems that isn't as much the case.

  • Folks, you got to remember that the target audience for ASP.Net was for vb6 developers who dreamed of writing webapps but didn't want to know anything about markup or asp developers who were pasta magicians.

    ASP.Net developers were never supposed to access the document dom themselves or peek at the markup, their vb6 developers for crying out loud or vbscript developers who couldn't write anything but spaghetti code - right?thats what Microsoft kept hearing when they asked for feedback.

    Thats why we have what we have.

    Things that were hard for newbies are easy, things that were easy for experts now become more difficult.

    I have to believe the standard page and controls simply aren't meant for everybody.

    Nothing prevents you from throwing all that away and doing your own architecture.

  • Someone needs to start a petition for a beta 3 or .Net 2.0. Maybe a suggestion should be submitted to the product feedback center.

  • Paul: You're making a lot of ridiculous assertions about me based on two sentences. I'd rather you didn't do that.

  • Agree I am on a petition for a Beta 3. It make sense when you see all the latest changes in community preview releases.

  • Paul, I have been harping on some of the same things. I've been blogging about these topics for a while. VS 2005 isn't ready. My shop at Pluck has fully deprecated v1.1. and are running on ASP.NET 2.0 Beta 2, so I'm in the trenches with this new product. The new web "sites" REALLY suck, and I hate them. The good news is that I've been able to "pursuade" VS 2005 into letting me use a class library project for web apps without any sacrifice of the IDE's features. I believe I'm going to start advocating a Beta 3.

    James, I know you, but you _have_ to be smoking crack if you like the new web projects. Here's a challenge for you: Make a web site, reference the Log4Net library. Create an NAnt build/deploy script for this. Check it all into Subversion (don't check in the Bin folder - which should be common sense). Go to a build machine, pull down the project from source control and run the build/deploy script. Then try to run the app on a web server. What? It didn't work. That, my friend, is what's wrong with the lack of a project file. Class library project in VS 2005 - no problem.

  • Well all this sounds really promising as an upgrade path.

    But at least the designer won't rewrite my HTML anymore right? Please tell me that at least works?

  • Jeff,

    Things are different that is for sure. You can't deploy like you used to, I agree with that. In your scenario some extra work needs to be done to make sure dependent assemblies are checked into source control and referenced by your build script, but in the end you actually have a cleaner deploy scenario. I prefer having explicit control over what is deployed.


    I am not trying to be better than anyone and I am not a "MS drone". It's a sad day where you can't state your opinion on something without the accusations flying. I have said in each of my posts I think they should have implemented both models and I stand by my OPINION that the web site model is a better representation of what will be deployed on the server. But I will say it again, they should have implemented BOTH models then we wouldnt be having these conversations and people could use whatever model they prefer.


  • WebSites in ASP.NET ARE Class Libraries. James if you think differently you are mistaken. They get compiled into dlls.

    Microsoft could have EASILY broken the IIS dependancy without removing the project file.

    I agree with the sentiment, they made ASP.NET 2.0 for mom and pop hobbyists instead of Enterprise application developers. I don't even see the point of using 2.0 given its current state.

  • Palermo,

    I almost forgot, some of those deployments issues will be fixed when nant is updated for 2.0. As it stands the project task doesnt support the new solution format right? This means it can't pick up where the references are stored.

  • "WebSites in ASP.NET ARE Class Libraries. James if you think differently you are mistaken."

    Well, they eventually get compiled into assemblies on the server but you still deploy .aspx files to the server which makes them a very different beast all-together.

  • In addition, if ASP.Net can support both styles, then we've got a winner. Project based "class library" ASP.Net running on the mini web server is perfect for enterprise developers.

  • I'm pretty slow on the uptake BUT....

    wouldn't the void caused by the loss of a project file be filled by an msbuild file? (or for now an NAnt build file). I mean, most of what is being talked about in a project file (dependancies, pre/post build events) could be done in a build file right?

    Or did I miss a memo between versions and I don't know that they've cut MSBuild from Whidbey? Is the build file the new project file and that's missing from the web projects.

    <--has WebDev Express installed, but hasn't opened it yet.

  • J. Palermo,

    "Go to a build machine, pull down the project from source control and run the build/deploy script. Then try to run the app on a web server. What? It didn't work."

    I see your point. That does suck. But does that work now? The way we've handled that is by creating a \lib directory and storing our binary dependancies in there. Right now they get copied to the /bin directory at compile time by VS, but I've been moving away from VS and starting to use makefiles/buildfiles.

  • For me ASP.NET should be able to produce output I'm proud of and be part of the development process I want.




    One source for all browsers OR I control it

    Automated tests that easy to implement


    Somewhere along the line this design seems to have focused on the Wizard driven developer and forgotten the "unassisted" developer.

    In 1.1 I find myself throwing out all the design surface stuff driven stuff. It doesn't really mean more work cause fixing the wizard stuff ofdten seems undoable!

    I haven't tested the version 2 stuff, but I was hoping they had made it more possible for the non wizard developer to use this stuff. This post fills me with despair. Has runaway complexity destroyed ASP.NET forever??

  • >Themes and Skins are one of the cool

    >new features of ASP.NET v2, but have you ever >stopped to think that they wouldn't be needed

    >we just used CSS stylesheets!

    Actually, that isn't quite true. CSS is a way of styling HTML tags. Themes are a way of styling ASP.NET controls. Since controls are potentially quite complex composite HTML entities, styling them entirely through CSS could actually be quite complex, and would require knowledge of the exact HTML emitted by the control. Being able to style all GridViews on a site in a consistent way (where each aspect of the grid style can be specified using CSS, of course) is actually quite nice.

  • Actually even the most complex web controls tend to have all their many properties also totally configurable by just a few CSS classes. For instance, on a grid you may have a bunch of header properties, footer properties, main item properties, alt item properties, and selected item properties, but they are all equally able to be set with just CSS classes for header, footer, main item, alt item, and selected item. The same is true for the calendar (now that title works) and even web parts (although the implementation does not work), as well as every other well-written control I've ever seen, no matter how complex. Yes there are probably some controls that don't offer this, but that's a reflection of a design that wasn't friendly to CSS classes and not the complexity of the control. And I'm sure there are only more of these unfriendly CSS controls partly because of the MS mentality that you create lots of properties instead of just simple CSS classes.

    Now as much as I don't plan on personally using themes and skins, I do see a huge need for them. Huh? That's right, the majority of ASP.NET web devs don't know how to use CSS classes and will thus hopefully come to love themes and skins! :)

  • With your background in Visual Basic and COBOL its pretty hilarious that you are so arrogant. At work there is a group of us that follow your blog just for the laughs. One person said that this isn't a blog as much as it is an homage to your ego.

  • Glad I can bring amusement to you and your buddies. By the way, just for my ego's satisfaction, my background is almost totally math, and then it was Delphi long before VB. By the way, I'm more inclined to delete anonymous posts, although I couldn't resist this one.

  • Sorry, I just realized that my comment was incredibly poorly written. End of a long day.

    What I was really trying to get at was that Themes let you style ALL instances of a control in one place (using CSS or not). That is, if you theme a control, you don't need to copy all of those styles to every instance of the control on your site - you set them once, and only have to change them in one place. It also makes it easier to rename styles (as you only have to change the style reference in one place) and to swap in and out entirely new style sets (swapping in a completely difference style sheet).

    Is it a huge win? No, but it can be convenient. I don't think of it as an alternative to CSS, just a more convenient way to apply it.

  • Kevin -- very nicely said. Of course it only works if your devs aren't setting properties and/or styles on the individual controls, since that would override your theme/skin. But if that's the policy that you enforce, and even for CSS that's always the hard part, then I agree that can be very useful.

  • To whomever likes to post anonymously and/or pretend to be someone else:

    Its bad enough to post anonymous drivel, but its far worse to post nonsense under the guise of someone else.

    While I try to approve anything that isn't spam, even if it is critical of me personally, I will be looking closer for now on to make sure that others are not being made to look badly.

  • >only works if your devs aren't setting

    >properties and/or styles on the individual


    Actually, themes override page-level control settings. Stylesheet themes, on the other hand, allow the page developer to override the theme settings. Ppersonally I find that naming to be unfortunate, as the distinction between the two types of themes isn't all that clear from the names.

  • for a joke that went too far. I will not bother you or your blog any further.

  • Kevin -- Wow! I did not know that! That has changed from the early alpha previews, and I guess I was so disappointed that I never bothered to keep up. Shame on me. I'll have to seriously rethink things and try more themes/skins -- although I'll still set css classes in those themes/skins. :)

Comments have been disabled for this content.