ASP.NET Don’ts and Do's
Some folks may keep falling into a trap and are unaware of what they are doing. This article highlights the Dos and the Don’ts in general regarding ASP.NET. The majority of the items listed are taken from the ASP.NET team recommendations. Though this may not be a complete checklist, it covers some of the most common “gotchas” folks run into.
If you know other tips about the Dos and Don’ts in ASP.NET in general, feel free to drop a comment so I can update the list.
Control Adapters
If some of you are still using Control Adapters, especially those WebForms folks- you should avoid it, as much as possible.
Avoid: Control Adapters, as these were created to support mobile controls rendering different markups for different devices.
Prefer: CSS media queries, responsive design and mobile specific views.
Style Properties on Controls
JavaScript Frameworks and AjaxControlToolkit
Try to Avoid: Mixing your jQuery code or other JS frameworks code with WebForm's AjaxControlToolkit controls to avoid functionality issues.
Prefer: Stick to the specific control libraries.
UpdatePanel Control
Do Not: Over use it (Think about performance and maintainability)
Do: Use it, when necessary and if it makes sense to use it.
Try to Avoid: It doesn’t help you to become a better web developer.
Prefer: AJAX e.g jQuery AJAX can be used to do asynchronous updates.
Page and Control Callbacks
Try to Avoid: Page callbacks or control callbacks.
Prefer: Anything else, e.g. Page Method,Web Service, AJAX, Web API.
Scripts and CSS FilesDo: Minify, bundle your CSS and Script files when deployed on production.
Try to Avoid: Deploying unminified scripts and CSS when you can minify them.
Static Script References
Try to Avoid: Referencing local script references (e.g jQuery)
Prefer: Use CDN (Content Delivery Network), when referencing is done on static files
But Always: Do a fallback local reference, in case CDN fails
Capability Detection
Try to Avoid: BrowserCaps, as it has a history of breaking as new browser versions are released
Prefer: Client-side feature detection and lightup, such as via Modernizr.
SQL Queries
Do Not: Append input values directly into your SQL statement because it can lead you to SQL Injection attacks. It’s a big NO NO!
Do:
(1) Use parameter queries
(2) Stored Procedures
(3) ORM e.g. Entity Framework, NHibernate etc.
This article highlights preventing SQL Injection. Protect Your Data: Prevent SQL Injection
Displaying of Data
Do Not: Display huge amounts of data in your page as it can affect the performance of your App and it is not user-friendly.
Do: Limit the amount of data to be displayed.
(1) Filter out items and load the associated data.
(2) Apply paging (e.g using custom paging with LINQ or using SQL paging).
(3) Apply data caching (but be careful: use it only where it makes sense).
Request Validation
Do Not: Depend on the request validation to protect your site against XSS attacks.
Do:
(1) Validate well-formedness of the data
“Is this user-submitted value, a valid System.Uri whose scheme is http: or https:?”
(2) Encode data on the way out.
CSHTML: @foo ● ASPX: <%: foo %>
(3) Don’t forget about JavaScriptStringEncode, UrlEncode, etc.
Cookieless Forms Auth& Session
Do Not: Enable cooki less forms authentication or session, as they could make your users victim to malicious attacks.
Do:
(1) Enable “require cookies” for these features.
(2) Consider using only secure (SSL) cookies for the sites serving sensitive information.
EnableViewStateMac
For the developers who use ASP.NET runtime <= 4.5.2
Do Not: Set EnableViewStateMac = false
Not ever: Not even on a single page.
“But I’m not using ViewState!” is not a valid excuse.
Do: Tease Microsoft for even allowing this as an option in the first place.
Well MS already forbids it when they released ASP.NET 4.5.2.
Medium Trust
Do Not: Depend on Medium Trust (or any other <trust> level) as a security boundary.
Do:
(1) Place untrusted Applications into their own Application pools.
(2) Run each Application pool under its own unique identity.
(3) You can follow some guidance.
<appSettings>
Do Not: Use <appSettings> to disable Microsoft security fixes for any lengthy time in production.
Do: Use Microsoft security-sensitive <appSettings>config as temporary compatibility that shims while rolling out Server upgrades or patches
Consult the list.
UrlPathEncode
Do Not: Use UrlPathEncode to encode the arbitrary user-provided strings.
Do:
(1) Sanitize inputs instead, checking submitted URL for well-formation.
(2) Use UrlEncode to encode the user input meant to appear as a query string parameter in the URL.
PreSendRequestHeaders&PreSendRequestContent
Try to Avoid: Registering for these events from within managed IHttpModule instances.
Prefer: Using native IIS modules, if you need to hook these asynchronous pipeline events.
Asynchronous Page Events
Try to Avoid: Writing async void methods [like Page_Load] for page lifecycle events.
Prefer: Using Page.RegisterAsyncTask() instead, if you need to register asynchronous work.
Do: Set <httpRuntimetargetFramework=“4.5” /> if using Task.
Response.Redirect& End
Be Aware: Reponse.Redirect(String) calls Response.End(), which aborts the current thread in synchronous requests and halts the code execution.
For asynchronous handlers, Response.End() does not abort the current thread, so code execution continues.
If you need to redirect the response, use the method appropriate for the framework you’re using. For example, in MVC, return a RedirectResult instead of calling Response.Redirect.
EnableViewState&ViewStateMode
Try to Avoid: Using EnableViewState.
Prefer:
(1) Set ViewStateMode=“Disabled” at page directive level.
(2) Set ViewStateMode=“Enabled” only on the controls that require state.
SQLMembershipProvider
Be Aware: Replaced by the UniversalProviders and ASP.NET. identity which works with all the databases and the Entity Framework supports including SQL, Azure SQL, SQL Compact, MySQL and more.
Long-Running Request
Try to Avoid
Session, as ASP.NET will forcibly release the session object lock at a potentially inopportune time
Blocking I/O operations.
Prefer
WebSockets, if possible, has much lower per-request memory overhead.
Real-Time Updates
Try to Avoid
The traditional way of pinging the Server for the updates with AJAX.
Prefer
ASP.NET SignalR. It provides a simple and clean API that allows you to create real-time web apps. HTML5 is also worth trying.
WebForms
Do Not
Stick to use Web Forms.
Do
• Learn other technologies that ASP.NET offers such as MVC, Web API, SignalR and ASP.NET Mobile.
• Learn JavaScript frameworks (e.g Angular, Knockout, React etc..).
• Keep up to date with what’s the latest and know the new features it offers.