The .NET Framework provides a variety of classes in the System.IO namespace that simplify working with the file system. Using these classes it's possible to delete files and folders, to create new files, to edit existing files, and more. These classes, combined with ASP.NET's suite of Web controls and databinding syntax, make it quite easy to present information about the files on the web server's file system to visitors to your website. With a bit of markup and code, it's possible to add a simple file browser to a web page that allows users to view the files and folders from a particular directory on the web server. Such file browsers are useful if you let users upload content to the website and need to let them view their uploaded content. If you have a folder that contains user-accessible content like images, PDF files and Word documents, a file browser offers a quick and easy way for users to see what content is available and to view content of interest.

Back in 2003 I wrote an article titled Displaying the Files in a Directory using a DataGrid that showed how to list the files of a particular folder in a DataGrid Web control. This dated article still attracts a decent amount of traffic and questions from readers, so much so that I thought it worthwhile to update the content to use the latest technology, namely ASP.NET 4 and the GridView Web control. I also added some new features. For example, the file browser now lists both files and folders, allowing users to view the files in subfolders. Also, I moved the markup and code into a User Control, which simplifies adding the file browser to an ASP.NET page. This article walks through this new, updated version; the complete, working code is available for download at the end of this article. Read on to learn more!
Read More >

Last week's article, Implementing the Store Locator Application Using ASP.NET MVC (Part 1), started a two-part article series that walked through converting my ASP.NET store locator application from WebForms to ASP.NET MVC. Last week's article stepped through the first tasks in porting the store locator application to ASP.NET MVC, including: creating the new project; copying over stylesheets, the database, scripts, and other shared content from the WebForms application; building the HomeController; and coding the Index and StoreLocator actions and views.

Recall that the StoreLocator action and view prompts the user to enter an address for which to find nearby stores. On form submission, the action interfaces with the Google Maps API's geocoding service to determine if the entered address corresponds to known latitude and longitude coordinates. If so, the user is redirected to the StoreLocatorResults action (which we create in this article) that displays the nearby stores in both a grid and as markers on a map. Unlike the StoreLocator action created in Part 1, the StoreLocatorResults action uses a more intricate model and a strongly-typed view. Read on to learn more!
Read More >

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. Read on to learn more!
Read More >

One of the new controls available with ASP.NET 4 is the QueryExtender control. The QueryExtender is designed to simplify filtering data returned from a LinqDataSource or EntityDataSource by decoupling the filtering logic from the data source control. Using the QueryExtender is easy - simply add a QueryExtender to the page, specify what data source control it applies to, and then define the filtering criteria. For example, when displaying product information on a web page you could use the QueryExtender control and a few lines of markup to display only those products that are not within a certain price range and whose name or category starts with a user-specified search string.

Filtering the data returned by a LinqDataSource or EntityDataSource control is certainly possible without the QueryExtender; both the LinqDataSource and EntityDataSource controls have a Where property that can be used to specify filtering criteria. What the QueryExtender offers is a simpler means by which to filter data. This article includes a number of demos (which can be downloaded at the end of this article) that showcase the QueryExtender's ease of use and its powerful filtering capabilities. Read on to learn more!
Read More >

An enumeration is a special type in the .NET Framework that is comprised of a number of named constants. While you might not have created an enumeration type yourself, you have likely used enumerations many times in day-to-day programming. For example, the rows in a GridView have a RowType property that returns an enumeration of type DataControlRowType that indicates the row's type: Header, Footer, DataRow, and so on.

When working with an enumeration we may need to display a descriptive message based on the enumeration's value. For example, using ASP.NET's Membership system you can programmatically create a new user account calling the Membership class's CreateUser method. This method specifies the success or failure of the operation via the MembershipCreateStatus enumeration. This enumeration has members like Success, InvalidUserName, InvalidPassword, DuplicateUserName, and the like. When calling this method from an ASP.NET page you might want to show the user a descriptive message based on this enumeration value.

This article explores three different ways to provide descriptive text for enumeration members. Read on to learn more!
Read More >

Chances are, there are several different URLs that point to the same content on your website. For example, the URLs http://yoursite.com, http://yoursite.com/default.aspx, http://www.yoursite.com, or http://www.yoursite.com/default.aspx are all likely valid URLs that results in the same content, namely the homepage for yoursite.com. While having four different URLs reference the same content may not seem like a big deal, it can directly impact your website's search engine placement and, consequently, it's traffic. To a search engine, those four different URLs represent four different pages, even though the all produce the same content.

To understand how allowing duplicate URLs in your website can affect your search engine placement, first understand that search engines base a page's placement in the search results based, in part, on how many other websites link to the page. Now, imagine that there are 1,000 web pages from other websites that link to your homepage. You might conclude, then, that a search engine would rank the importance of your homepage based on those 1,000 links. But consider what would happen if 25% of those links linked to http://yoursite.com, 25% to http://yoursite.com/default.aspx, and so on. Rather than your homepage reflecting 1,000 inbound links, instead the search engine assumes there are only 250 links to http://yoursite.com, only 250 links to http://yoursite.com/default.aspx, and so on. In effect, redundant URLs can dilute your search engine ranking.

A key tenet of search engine optimization is URL normalization, or URL canonicalization. URL normalization is the process of eliminating duplicate URLs in your website. This article explores four different ways to implement URL normalization in your ASP.NET website. Read on to learn more!
Read More >

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. Read on to learn more!
Read More >

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. Read on to learn more!
Read More >