Dot Net Tricks

There I said it.  My co-worker Pete and I have been discussing this.  ASP.NET has become in my mind, too complicated.  I’ve worked with web related technologies for years.  I started with Coldfusion.  I used classic ASP (and still do on legacy websites.) I did Java and JSP in school and have been playing with Ruby On Rails lately.  Of all of them, ASP.NET has the most quirks and complexity. 

Now, I’m not talking languages here.  I love C# and the .NET framework.  I think overall they are simple, fairly consistent and easy to get things done in.  But ASP.NET webforms has gotten out of hand.

Things I hate about ASP.NET:

• The event lifecycle.  You have to know the order of the events: Init, Load, PreRender, the ItemDataBound and RowDataBound events of grids, datalists and repeaters, Click and OnItemSelected events, etc, etc.  To really get anything done that’s out of the ordinary, the developer has to know this event system and its order really well.  I know others have bitched about this as well.
• ViewState. Now you have it, now you don’t.  Forget about page weights and performance problems—that’s not usually and issue in most of my applications.   Viewstate is not consistent.  ViewState is around during the Load event but not during Init.  If you dynamically load a user control or programmatically add a button, textbox or other control, ViewState doesn’t remember that control.  You have to add it again each time.  ViewState doesn’t remember things like the event handler you wired up to a button on the previous postback.   ViewState isn’t very object friendly.  You can put objects into ViewState, but they better be small and serializable.  Oh, and in asp.net 2.0?  Now we have Viewstate and ControlState.  I know there are reasons for all of this and I appreciate what Microsoft was trying to do.  But viewstate tends to make things more complicated than they have to be. Its inconsistent and problematic.
• Pages, Server Controls, User Controls, oh my!  Why in God’s green earth do we have user controls?  Why can’t you just reference another page or add it to the current page’s control collection.  In the old ASP days, you could just include pages into other pages or browse to them directly. Why is it if I want to reuse the content and functionality of a page, I must first convert it to a user control?  And if I want to have a set of reusable methods and properties in a base class, I can make one base class and have all my pages inherit from it but the user controls will not get any of this functionality.  So then I have to make two base classes or do something else.   And why can’t you reference a user control in another project or website?  Why can’t user controls be fully compiled (both the html and C#) as a DLL that can be reused the way server controls are now?   Why do we have Server Controls AND User Controls?  Why can’t you just have the option of doing everything in C# like Server Controls, or wiring up some Html to the Code behind like pages and user controls?  This split between pages, user controls and server controls adds more complexity than is needed.
  
• Compilation.  ASP.NET used to be a lot simpler in 1.1 as far as compilation.  Now we have project-less Websites, Web Application Projects (my preference) and we have Web Deployment Projects.  If you use websites, compiling takes a really long time.  If you use Web Applications, Save & Continue is limited, and if you have too many files added, Visual Studio’s performance suffers.  On really large web app projects with lots of files, it takes forever to remove references or add or delete files.  Web Deployment projects are another beast.  If you are using a deployment project with a WEBSITE, then you have the option of compiling everything into one DLL, as opposed to having each page and directory get built as DLLs like the default VS.NET behavior.  However, if you have a naming collision in your classes or namespaces, you won’t notice this when you compile your website using Visual Studio (because all the pages are separate DLLs) but you WILL get errors when you compile the website using a Web Deployment Project (because everything gets combined into one DLL.)  If you are using web deployment projects with web applications, get prepared for more pain.  The deployment project completely ignores your web application’s .csproj file.  It will attempt to build everything in that directory including pages and .cs files that you specifically excluded from the project.  However, if you attempt to use web publishing in VS.NET with web application projects, then it doesn’t copy stuff like javascript, css, images etc. that are not included in the project.  Again, you may not want to include all this stuff in your project because it slows to a crawl if you have too many files in it.  Finally, if you like using Web Apps but not Websites (or vice versa), but a third party shopping cart or something uses the them, conversion from one to the other is painful.  Things that dynamcially get compiled on the fly like the profile class break conversions to Web App Projects.
• Related to compiling, I hate how when you compile asp.net 2.0 sites, it puts a reference to the exact name of the DLL in the page directive.  This means if you change the name of the DLL in your web app or web deployment project, the page will not work unless you also update the BIN folder.  Website projects are EXTREMELY bad with this, as they semi-randomly create a filename name every time for the website's DLLs.  This really complicates your ability to just update a few pages or controls. - ADDED 4/12/2007
  
• I love how datasource controls allow you to have two way declarative databinding.  I hate the two built-in datasource controls.  SqlDataSource wants you to write SQL in your page like Coldfusion.  ObjectDataSource wants you to write you business layer in a very specific and procedural way that is not very OO at all.  Enough said.
• Displaying variables in your Html: you can use the old <%= %> but if you do that you will get errors if you modify the page’s control collection.  You can use <%# %> for databinding expressions, but you must call databind() on the page or a control in the code-behind.  Its very easy for this to wrong unless you know what you’re doing.   Lets say you have a page with some user controls loaded.  If you call databind() on the page, it will also recursively call databind() on its child controls.  If they don’t have their data yet, you may get errors.
• Security Exceptions. I think its great that .NET is more secure.  I hate how permissions inevitably get fouled up and you find that ASP.NET does not have permission to do what it needs to do on your site.  Then you have to go in and re-add permissions to files and folder.  On a windows XP machine, this is the ASPNET login.  On a windows 2003 machine, its Network Service.
• The controls hierarchy.  Ever try to reference a server control like a button or text box thru Javascript?  A textbox with the ID “FirstNameTxt” becomes something like “ctl0_userCtl1_panel3_FirstNameText”.  You have to use the ClientID property and somehow reference that from javascript using databinding or a literal control.
• Unrelated to ASP.NET directly, but still related to building websites with Microsoft technologies:  Why can’t I have multiple websites in IIS on windows XP without resorting to some third party application?  Why can’t I have the same version IIS running both on my development box and my production box?  Consistency between development, testing and production is really important Microsoft!
  

I give Microsoft credit for trying to make developing webforms very similar to developing winforms.  I understand that they were trying to add events and statefulness to the web, which has neither.  But the implementation has become too bloated and complex, and too difficult when you’re not doing something simple.

Please note that I am a very experienced ASP.NET developer.   I know it pretty well and still have problems with some of the things mentioned above.  Try getting a developer that is not quite as experienced with ASP.NET and they will pull their hair out.  There are many things I DO love about ASP.NET.  The unnecessary complexity is not one of them. 

I would love to hear anyone’s thoughts on this subject, especially from Microsoft.