Scott Hanselman

Checklist: What NOT to do in ASP.NET

February 08, 2014 Comment on this post [23] Posted in ASP.NET
Sponsored By

Damian Edwards at NDC 2013 talking about ASP.NETAbout 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.

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
February 08, 2014 2:10
I personally thank you for the guidelines; as always the best from you. Also recommend everyone to please follow them as much as possible.
February 08, 2014 2:18
Web API, SingnalR and all the open source stuff makes this stack so sexy, but calling it ASP.NET is like sexy lady putting on homeless man hat...

February 08, 2014 2:20
That was a great session, I had already watched it. But, it's nice to have this list. This got clipped to Evernote!
February 08, 2014 3:12
Thanks for the list. It's helpful and a confirmation as I do all of it.
February 08, 2014 8:31
Nice list! However, most of them apply to WebForms, not MVC...
February 08, 2014 8:50
Great checklist. I wonder what would be the best approach to automating checking for these. R# Structural Search perhaps, or fxCop rules?
February 08, 2014 11:41
Great list. Some parts are not present in plain ASP.NET 3.5 and Sharepoint 2010. Is there guidance available for using the advice for older versions of ASP.NET?
February 08, 2014 12:18
Thank you Scott! Nice and useful summary.

@Arslis: but it IS asp.net.
how do you call it then?

February 09, 2014 0:57
"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."

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.
February 09, 2014 2:33
Make it an AJAX call?
February 09, 2014 11:11
Do NOT use AntiXSS because it's broken

http://wpl.codeplex.com/releases/view/80289#ReviewsAnchor
February 10, 2014 13:43
"Don't pass anything auth related in the query string. Cookieless auth will never be secure. Don't do it."

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?
February 11, 2014 15:27
Thanks dude for such a awesome list...
February 11, 2014 21:59
Don't use control adapters? This is the worse advice I've ever heard! Most ASP.NET server controls still emit old fashioned table layouts and obtrusive JavaScript code that can't be removed unless you use control adapters. .NET 4 supposed new rendering mode attributes are only supported on a few controls and still emits yucky CSS classes and JavaScript that pollutes your code.
February 12, 2014 23:50
Good post Scott!
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
February 17, 2014 8:03
nice article Scott,
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
February 17, 2014 20:57
ASP.NET is an outdate technology now, it sticks on M$ Visual Studio. Even there is no choice, developer should choose ASP.NET of Mono.
February 25, 2014 2:17
Interesting. Time to dig on SignalR, Web API.
February 25, 2014 7:20
Nice one.

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!
February 26, 2014 13:56
Ouch... Been using SqlMembershipProvider for all my projects. Time to upgrade.
March 03, 2014 18:47
What do you think is the right approach is for those 5+ year old enterprise web apps that have many of those items checked off? At one point many of those in the list where the recommended way. These enterprise web apps are constantly being upgraded to the latest version of .Net so that Devs can use the last VS tooling but there basic implementation is still the same.
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.
April 01, 2014 1:58
Good news. Long-running ASP.NET request can be handled seamlessly with the help of Fire-And-Forget Work. I know that I'm breaking two rules at one blow, but there is a handy solution – HangFire (it is available as a NuGet package). It is based on job queues, reliable fetching, auto-retries and has web interface to track the state of each job. It does not require windows service and can be hosted directly in ASP.NET application (however, you can host it in windows service too).
It is inspired by Resque, Sidekiq and other background job processing systems from different platforms that already processed millions of jobs.
May 09, 2014 5:56
Nice post and thanks for the tutorial!

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.