Checklist: What NOT to do in ASP.NET
About a year ago we thought it would be a good idea to do a talk on "What not to do in ASP.NET?" - basically an anti-patterns talks. We kept seeing folks falling into the same traps and wanted to be prescriptive as there's aspects to ASP.NET that are 10 years old and don't apply to today's internet, but there are also new aspects to ASP.NET that are only a year old, and perhaps haven't soaked into the zeitgeist quite yet.
Damian Edwards gave his version of this talk at NDC 2013 and you can watch the video here if you like, it's very entertaining.
We took the information we gathered from people like Damian, Levi Broderick and others, and Tom FitzMacken put together a whitepaper on the topic. It's not complete, but it covers some of the most common "gotchas" folks run into.
Here are the areas we call out in the whitepaper so far, with highlights below from me.
- Standards Compliance
- Control Adapters - Control adapters were a good idea in .NET 2, but it's best to use solid adaptive CSS and HTML techniques today.
- Style Properties on Controls - Set CSS classes yourself, don't use inline styles.
- Page and Control Callbacks - Page Callbacks pre-date standard AJAX techniques, so today, stick with SignalR, Web API, and JavaScript.
- Browser Capability Detection - Check for features, not for browsers whenever possible.
- Security
- Request Validation - While Request Validation is useful, it's not focused and it doesn't know exactly what you app is doing. Be smart and validate inputs with the full knowledge of what your app is trying to accomplish. Don't trust user input.
- Cookieless Forms Authentication and Session - Don't pass anything auth related in the query string. Cookieless auth will never be secure. Don't do it.
- EnableViewStateMac - This should never be false. Ever.
- Medium Trust - Medium trust isn't a security boundary you should count on. Put apps in separate app pools.
- <appSettings> - Don't disable security patches with appSettings.
- UrlPathEncode - This doesn't do what you think it does. Use UrlEncode. This method was very specific, poorly named, and is now totally obsolete.
- Reliability and Performance
- PreSendRequestHeaders and PreSendRequestContext - Leave these alone making managed modules. These can be used with native modules, but not IHttpModules.
- Asynchronous Page Events with Web Forms - Use Page.RegisterAsyncTask instead.
- Fire-and-Forget Work - Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.
- Request Entity Body - Stay out of Request.Form and Request.InputStream before your handler's execute event. It may not be ready to go.
- Response.Redirect and Response.End - Be conscious of Thread.Aborts that will happen when you redirect.
- EnableViewState and ViewStateMode - There's no need to hate on ViewState. Turn it off everywhere, then turn it on only for the individual controls that need it.
- SqlMembershipProvider - Consider using ASP.NET User Providers, or better yet, the new ASP.NET Identity system.
- Long Running Requests (>110 seconds) - ASP.NET isn't meant to handle long running requests that are a minute (or two) long. Use WebSockets or SignalR for connected clients, and use asynchronous I/O operations.
I hope this helps someone out!
Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
@Arslis: but it IS asp.net.
how do you call it then?
So assuming we want to work with older browsers, that means SignalR?
Assuming a simple long-running task (user presses button, task starts, progress is shown on page and a 'cancel' button is available), what's the canonical way of implementing this when you have MVC on the back end?
I've done this various ways, so I'm just curious what others' opinions are on what the 'best' way is.
http://wpl.codeplex.com/releases/view/80289#ReviewsAnchor
Well, when you need to host several web browser controls in your application and you need each instance to have its own ASP.NET session, cookieless is the only way to go. Or is there any alternative to this scenario?
I think most of these misusing comes from confusion, misconception or need of better reference samples with good defaults, blog posts (like yours ;) , or the asp.net-link you direct to), Books etc...
Viewstate
I have tried to show the resource below to many asp.net-developers
- wich I personally like for clarifying viewstate and possible outcomes of ignoring to set it to "off" where not needed (using web.archive to show the funny pictures :D )
I hope you and others will like it too ^^
TRULY UNDERSTANDING VIEWSTATE
http://web.archive.org/web/20081227082841/http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
Suggestion?
Here's one suggestion, enable good default's for viewstate in visual studio => Set default values for standard Visual Studio templates for making aspx-pages, masterpages etc to set it off everywhere?
Response.Redirect and Response.End
It got my attention first only after reading P&P-guideline not from any ASP.NET-book.
Tried to target attention to this behaviour in Errata for MCTS Self-Paced Training Kit (Exam 70-515): Web Applications Development with Microsoft® .NET Framework 4
http://www.oreilly.com/catalog/errata.csp?isbn=9780735627406
where I link to the P&P-page
http://msdn.microsoft.com/en-us/library/ff647787.aspx#scalenetchapt06_topic22
i think most of the developer just don't do that after all because the list is for advance dev's. those novice dev's are just following the default setting that asp .net brings.
cheers
The problem with the statement of "use websockets" is that feature was not backported to server 2008 r2, and there are still many firms running on IIS 7.5 for a while. So if you don't have 2012, then no websockets.
It should've been added to 2008 r2 as well!
Rewrite if possible would be my choice because pulling those things out and retooling them out would be a tough sell. From the business user point of view your not really changing anything functionally. Of course re-write in many enterprises is almost universally dismissed. Maybe another blog post perhaps.
Thanks for list, pointing these things out make it very helpful to break yourself out of the same design/dev mold.
It is inspired by Resque, Sidekiq and other background job processing systems from different platforms that already processed millions of jobs.
Comments are closed.