.NET news » Search results

When a browser requests an ASP.NET page from a web server, the ASP.NET engine takes that request through a number of steps that, together, generate the resulting markup, which is returned to the requesting browser for display. The stages in this process are referred to as the HTTP Pipeline and perform tasks like authentication, authorization, and having the requested page render its content. During one of the later stages in the HTTP Pipeline the rendered markup is handed off to a response filter which, if supplied, has an opportunity to inspect and modify the markup before it is returned to the requesting browser.

With a little bit of code you can create your own response filters and associate them with a particular page, a particular type of page (such as ASP.NET resources that generate HTML), or for all ASP.NET resources. And if you are using IIS 7s integrated mode you can have your filter work with the output of any content type. This article provides an overview of response filters and shows two such filters: a naive filter that strips out whitespace to reduce the size of the markup sent over the wire, and a filter that adds a copyright message to the bottom of all web pages. You can download these two filters, along with a simple demo application, at the end of this article, with examples in both C# and Visual Basic…

Search engine optimization, or SEO, is the practice of improving a website's position in search engines' results using unpaid techniques. The driver behind SEO is that a better (higher) position in the search results will, most likely, lead to more click throughs, increasing the website's visibility, audience, and profit. A previous article here on 4Guys, Search Engine Optimization Enhancements in ASP.NET 4, explored some of ASP.NET 4's new features designed to aid with SEO. Another helpful tool for SEO is Microsoft's SEO Toolkit, a free IIS add-on that you can run from your computer to inspect a local or remote website and identify potential issues that may impact its search engine rankings.

Using Microsoft's SEO Toolkit is simple. Once installed, run it and specify the website you want to analyze. The SEO Toolkit can analyze both local websites or remote ones. After you've specified the URL of the website to analyze, the SEO Toolkit will crawl the site, exploring its pages and identify potential issues that may affect the site's search engine rankings and offer suggestions on how to fix them. This article walks through getting started with the SEO Toolkit, showing how to use it and how to analyze its results and implement its suggestions to help improve your website's search engine placement.

When a browser displays the HTML sent from a web server it parses the received markup into a Document Object Model, or DOM, which models the markup as a hierarchical structure. Each element in the markup - the <form> element, <div> elements, <p> elements, <input> elements, and so on - are represented as a node in the DOM and can be programmatically accessed from client-side script. What's more, the nodes that make up the DOM have functions that can be called to perform certain behaviors; what functions are available depend on what type of element the node represents.

One function common to most all node types is focus, which gives keyboard focus to the corresponding element. The focus function is commonly used in data entry forms, search pages, and login screens to put the user's keyboard cursor in a particular textbox when the web page loads so that the user can start typing in his search query or username without having to first click the textbox with his mouse. Another useful function is select, which is available for <input> and <textarea> elements and selects the contents of the textbox.

This article shows how to call an HTML element's focus and select functions. We'll look at calling these functions directly from client-side script as well as how to call these functions from server-side code.

Back in May 2010 I wrote a three-part article series titled Building a Store Locator ASP.NET Application Using Google Maps API, which showed how to build a simple store locator application using ASP.NET and the Google Maps API. The application consisted of two ASP.NET pages. In the first page, the user was prompted to enter an address, city, or postal code (screen shot). On postback, the user-entered address was fed into the Google Maps API's geocoding service to determine whether the address, as entered, corresponded to known latitude and longitude coordinates. If it did, the user was redirected to the second page with the address information passed through the querystring. This page then queried the database to find nearby stores and listed them in a grid and as markers on a map (screen shot).

Since the WebForms store locator application was published, several readers have emailed me to ask for an ASP.NET MVC version. I recently decided to port the existing WebForms application to ASP.NET MVC. This article, the first in a two-part series, walks through creating the ASP.NET MVC version of the store locator application and pinpoints some of the more interesting and challenging aspects. This article examines creating the ASP.NET MVC application and building the functionality for the user to enter an address from which to find nearby stores. Part 2 will examine how to show a grid and map of the nearby stores.

Traditionally, web applications have left a lot to be desired from a user experience standpoint, due primarily to the "request/response" lifecycle. Any interaction with a page typically requires a postback to the web server (a "request"), which then performs any server-side tasks needed and returns the updated page's markup (the "response"). Outside of intranet-based applications, such behavior adds a bit of a lag when interacting with a page. One approach to improving the end user's experience is to use AJAX. AJAX is a technique for using JavaScript and the XMLHttpRequest object to make light-weight HTTP requests back to the web server from client-side script. Once a response is received, the web page's layout can be seamlessly refreshed using JavaScript to message the page's Document Object Model (DOM) and CSS settings. AJAX-enabled pages provide a slick, responsive user experience, making web-based applications function more like desktop-based ones.

In the past adding AJAX type behaviors to your web application was difficult and came with a steep learning curve since AJAX encompasses a bevy of technologies (JavaScript, XML, XmlHttpObject, HTTP requests, DHTML, and so on). With the advent of the ASP.NET Atlas framework, however, there is much less of a reason to feel so overwhelmed when it comes to AJAX!

When creating ASP.NET 2.0 applications, developers commonly store sensitive configuration information in the Web.config file. The cannonical example is database connection strings, but other sensitive information included in the Web.config file can include SMTP server connection information and user credentials, among others. While ASP.NET is configured, by default, to reject all HTTP requests to resources with the .config extension, the sensitive information in Web.config can be compromised if a hacker obtains access to your web server's file system. For example, perhaps you forgot to disallow anonymous FTP access to your website, thereby allowing a hacker to simply FTP in and download your Web.config file. Eep.

Fortunately ASP.NET 2.0 helps mitigate this problem by allowing selective portions of the Web.config file to be encrypted, such as the section, or some custom config section used by your application. Configuration sections can be easily encrypted using code or aspnet_regiis.exe, a command-line program. Once encrypted, the Web.config settings are safe from prying eyes. Furthermore, when retrieving encrypted congifuration settings programmatically in your ASP.NET pages, ASP.NET will automatically decrypt the encrypted sections its reading. In short, once the configuration information in encrypted, you don't need to write any further code or take any further action to use that encrypted data in your application.

In this article we'll see how to programmatically encrypt and decrypt portions of the configuration settings and look at using the aspnet_regiis.exe command-line program. We'll then evaluate the encryption options ASP.NET 2.0 offers. There's also a short discussion on how to encrypt configuration information in ASP.NET version 1.x.

The ASP.NET WebForms model aims to simplify web development by blurring the line between the client and the server. In short, WebForms allow the page developer to set aside the fact that the browser and the web server are temporally, physically, and logically disconnected. The page developer can create server-side event handlers that execute in response to a client-side action (like clicking a button). He can make server-side changes to properties of Web controls on the page and need not worry about reinstating those properties on the subsequent postback. One of the essential ingredients for performing this magic is view state.

View state represents the state of an ASP.NET web page that is to be remembered across postbacks. On each page visit, an ASP.NET web page automatically constructs this state information and stores it to a hidden form field on the page named __VIEWSTATE. When the form is submitted, the browser returns this hidden form field to the server; the ASP.NET page then parses the view state information to reconstruct the state from the previous page visit. This entire process happens automatically behind the scenes and is, in part, what makes ASP.NET web development so accessible.

Unfortunately, there is no such thing as a free lunch, and view state is no exception. The presence of view state adds to the size of the page, thereby resulting in larger page sizes that can negatively effect the user experience. What's more, certain controls - such as DropDownLists and GridViews - can significantly add to the heft of a page's view state. It's a good practice for WebForm developers to keep an eye on their pages' view state sizes to ensure an optimal user experience. This article two ways to programmatically determine a page's view state size and to provide a warning should the view state size exceed some specified threshold.

The ASP.NET Web Forms model strives to encapsulate the lower level complexities involved in building a web application. Features like server-side event handlers, the page lifecycle, and view state effectively blur the line between the client and the server, simplify state management, and free the developer from worrying about HTTP, requests and responses, and similar matters. While these facets of the Web Forms model allow for rapid application development and make ASP.NET more accessible to developers with a web application background, their behavior can impact your website's behavior and performance.

View state is perhaps the most important - yet most misunderstood - feature of the Web Forms model. In a nutshell, view state is a technique that automatically persists programmatic changes to the Web controls on a page. By default, this state is serialized into a base-64 encoded string and included as a hidden <input> field in the Web Form. On postback, this state information is returned to the server as part of the POST request, at which point the server can deserialize it and reapply the persisted state to the controls in the control hierarchy. (If this last paragraph made crystal clear sense, great! If not, consider reading my article, Understanding ASP.NET View State, and Dave Reed's article, ViewStateMode in ASP.NET 4, before continuing.)

One potential issue with view state is that it can greatly bloat the size of your web pages. Each new version of ASP.NET seems to include new techniques for managing view state's footprint. ASP.NET 4 adds a new property to all Web controls, ViewStateMode, which allows developers to disable view state for a page by default and then selectively enable it for specific controls. This article reviews existing view state-related properties and then delves into the new ViewStateMode property.

In .NET applications, an illegal operation - an invalid cast, attempting to reference a null value, trying to connect to a database that's been taken offline, and so on - raises an exception. Exceptions can be caught and handled directly in code through the use of Try / Catch blocks. For ASP.NET applications, if the exception is not handled in code, it bubbles up to the ASP.NET runtime, which raises an HttpUnhandledException. By default, unhandled exceptions result in a page that displays the text, "Runtime Error" with instructions for developers on how to display exception details (see the screen shot to the right). This "Runtime Error" error page is what is seen by external visitors; if you visit your site through localhost and an unhandled exception occurs, the default error page includes the type and details of the exception thrown.

End users will no doubt find the "Runtime Error" page to be intimidating and confusing - do you think the average computer user knows what "Runtime" means? All the user knows is that something went horribly wrong. They might fear that their data or progress has been lost and that they are responsible for the error. Ironically, the person who does care that an unhandled exception has occurred - the developer - is left out of the loop unless the end user takes the time to email the developer the details of the error (what page it happened on, the steps the user had performed that caused the error, and so on)..

Many of the built-in ASP.NET server controls require additional, external resources in order to function properly. For example, when using any of the ASP.NET validation controls, the controls rely on a bevy of JavaScript functions to perform their client-side validation. While each validation control could emit such script directly into the page's content, a more efficient approach would be to package these JavaScript functions into an external JavaScript file and then include that file in the page using <script src="PathToExternalJavaScriptFile" type="text/javascript" >. This would reduce the total page size and would allow the browser to cache the external JavaScript file (rather than having to send the JavaScript code down to the browser on each and every page visit/postback).

Prior to ASP.NET 2.0, such external resources that needed to be accessible to the visitor's browser had to be implemented as actual files on the file system. If you've worked with ASP.NET 1.x's validation controls, your pages have included a reference to a JavaScript file /aspnet_client/system_web/version/WebUIValidation.js and there is an actual file with that name residing in the web application's root. Such external resources hamper deployment - if you deploy your application from the testing server to production, it's imperative that the production server have the same external resources (WebUIValidation.js, in this case), in the same locations in the file system.

To remedy this, ASP.NET 2.0 allows for external resources to be embedded within the control's assembly and then be accessed through a specified URL. With the external images, JavaScript files, CSS files embedded in the control's assembly, deployment is a breeze, as all of the resources are now contained within the assembly (the .dll file). There are no external resources whose file names and location on the file system must map up. Once embedded into the assembly, these resources can be accessed from an ASP.NET 2.0 web page through a special URL (WebResource.axd)..