WynApse Home Page
Home    Blog    About    Contact       
Latest Article:

My Tags:
My Sponsors:

Lifetime Member:

Adding URL Rewriting to your Site

The Funky URL Problem

I have my site setup with just two pages, Default.aspx and ContentPage.aspx. Depending upon the article displayed, data is read froDm the database and displayed in the center area giving the whole site a consistent look.

The only problem with the setup was my page urls became something like


which is not descriptive, is not easily remembered, and is not good for SEO (Search Engine Optimization).

Scott Cate gave a talk at Desert Code Camp I on URL Rewriting, and I finally took the plunge and implemented that.

The code was actually deceptively simple, and as with a lot of things, I was making it harder than it needed to be because I was expecting it to be hard.

The Solution

I used UrlRewritingNet.UrlRewrite which is extremely well-done and the reason for the process being simple.

I followed the directions in the documentation, which were straightforward, but was a bit confused by the description of how to setup the URL name translation. The Regular Expression usage demonstrated in the documentation and the sample just didn't apply directly to my situation.

I ratted around and found this blog entry from .NET RUSH, which talked directly to the modifications to the web.config file which I had done, and a little more about the URLs.

John Bland talked about it in his blog as well here, but I still didn't "get it".

Finally I went back to the information from Scott Cate from May 2006, and somewhere along the line the realization of how the translation happened kicked in.

To summarize, download the sample code from the UrlRewriteingNet.UrlRewrite folks, and copy and paste from the sample web.config as follows:

Put this code in right at the top of web.config, as the first thing below <configuration>:

 nbsp;nbsp;<section name="urlrewritingnet" requirePermission="false" type="UrlRewritingNet.Configuration.UrlRewriteSection, UrlRewritingNet.UrlRewriter"/>

Place the following inside <system.web>. I put it at the bottom of the section and it worked fine there:

   <add name="UrlRewriteModule" type="UrlRewritingNet.Web.UrlRewriteModule, UrlRewritingNet.UrlRewriter"/>

Then just above </configuration> I put this line:

<urlrewritingnet configSource="ExternalRewrite.config"/>

This is the code suggested to allow an external config file to be used.

The ExternalRewrite.config file looks something like this:

<urlrewritingnet rewriteOnlyVirtualUrls="true"


      <add name="Rule001"

      <add name="Rule002"


Please refer to the online UrlRewritingNet.UrlRewrite documentation for their suggested use. I'm only detailing my specific application and it may be different from your needs.

In the above code, Rule001 and Rule002 are names to identify the individual rules. There must be a uniquely named one for each rule in your urlrewritingnet section.

The virutalUrl is the fake URL that your users will see, and that you will have to use internally. Notice the folder structure implied by the naming.

Also notice the syntax "^~/[folder(s)]/file.aspx".

The only other part is the real target URL to your product. In my situation, the urls are all the same, they simply target unique record names: "~/ContentPage?Event=[some ID]".

I initially got it all working with the urlrewritingnet secion inside web.config, and then pulled it out separate, but now that I know it works for me, I wouldn't hesitate to do that. My whole site concept is making database changes to add product to the site. If I'd have had to have the URLS in web.config, it would have left me with having to ftp the whole site up for any changes made.

Once I had this working and knew it worked on my site, I had a few global changes to make. Internal links were using the "Event=" code, and although they resolved correctly, they still showed up in the browser with the numerical links. Some of these were embedded in the page code in the database and some was in other tables.

I decided on a naming scheme for the existing files and modified all my tables to be consistent, then built all my rewrite definitions to match.


The only drawback I can think of is that I have one more file to update when I add a new article, because of how I am using the tool. I have to add the article index, link, and subject information into one table, upload the markup text to the page table, and now ftp the modified rewrite section. It's only one more file and the information is all contained in the other two files, so it's not a huge deal.


I like that my pages have a human-readable format, and that the subject name can appear to be a folder, so the organization of pages, although virtual, is consistent.
Copyright © 2006-2017, WynApse