Some folks may keep falling into a trap and are unaware of what they are doing. This post 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. :)
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
- Try to Avoid: The four thousand specific control style properties, e.g.
- Using inline CSS styles, e.g.
- Prefer: CSS stylesheets. You can roll your own or use Bootstrap or a combination of your own CSS.
- 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.
- 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 Files
- Do: 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
- 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.
- 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!
(1) Use parameter queries (2) Stored Procedures (3) ORM e.g. Entity Framework, NHibernate etc.
This article highlights the prevention of 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).
- Do Not: Depend on the request validation to protect your site against XSS attacks.
Cookieless Forms Auth& Session
- Do Not: Enable cookieless forms authentication or session, as they could make your users victim to malicious attacks.
(1) Enable “require cookies” for these features. (2) Consider using only secure (SSL) cookies for the sites serving sensitive information.
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. :D
Well MS already forbids it when they released ASP.NET 4.5.2.
- Do Not: Depend on Medium Trust (or any other
level) as a security boundary.
(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 here: https://support.microsoft.com/en-us/kb/2698981.
- 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 here.
- Do Not: Use UrlPathEncode to encode the arbitrary user-provided strings.
(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 life-cycle events.
- Prefer: Using
Page.RegisterAsyncTask()instead, if you need to register asynchronous work.
- Do: Set
Response.Redirect & End
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
EnableViewState & ViewStateMode
- Try to Avoid: Using EnableViewState.
(1) Set ViewStateMode=“Disabled” at page directive level. (2) Set ViewStateMode=“Enabled” only on the controls that require state.
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.
- 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.
- 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.
- Do Not: Stick to use Web Forms.
Reference: What Not to Do in ASP.NET