Before IIS7, the main method for allowing users to download files of a protected type (exe, zip, etc.) meant writing a function based off the Stream method and writing the file out based on individual name. Thankfully with IIS7+ there is a much easier way.

First, I would recommend that all files meant for internet user download be maintained in a separate virtual directory. For example, if your site was called www.mysite.com, the downloadable files should be in a directory like www.mysite.com/userdownloads. Once the files are in place, you need to do the following:

1)  Open the IIS 7.0 (or later) Manager on the server

2)  Select the site and click on "Handler Mappings"

3)  Select "Add Module Mapping"

4)  Enter the fields on the window:

     a)  Request Path:   where are the files to be found don't put a leading slash.  Example: "userdownloads/*.exe" to allow all files in the userdownloads directory ending in .exe to be downloaded when the request is for any executable file within the virtual path that you would have defined earlier.

     b)  Module:  StaticFileModule - this will handle requests containing your request path and return the file to you.

     c)  Executable:  don't enter anything.

     d)  Name:  whatever you want to call it:  "ClientSide Executables"

5)  Click on "Request Restrictions" and click on the checkbox and ensure that "File" option is selected.  (This will only apply to files)

6)  Click on the "Access" tab.  Ensure that "Script" is selected.

7)  Click on "OK" to close this window

8)  Click on "OK" to close the main Handler screen.

9)  Your handler should now appear in the list with the other handlers. 

10)  Test it out by opening a browser and accessing an executable file.

Here at eSource, we use blogengine.NET to run our blog. There are many other platforms out there for IIS that offer the same functionality, and they all offer the same basic bells and whistles.

One really neat feature is the sitemap.axd file. It actually doesn’t exist in hard form, it is created on the fly (as requested) and returns the latest list of all pages within the blog library. The problem with blogengine.NET and other major IIS blog providers is that they don’t let you add additional sites to the sitemap.axd file unless they are part of the overall blog database. For eSource (and other blogs) it is necessary to have a sitemap that is created in real time to ensure the latest pages are added, but also include some pages that are outside of the administration page listings in the control panel.

Download the .EXE and config sile: Sitemap2XML.zip (3.91 kb) 

(requires IIS7 or greater with .NET Framework 2.0 or greater).

This is not a big deal when submitting your sitemaps to Google, but Yahoo and Bing only allow one sitemap to be assigned to each site. In Google’s case, you would simply specify sitemap.axd as the main sitemap, then add a manually created .XML file to include all of your otherwise non indexed pages. But for the other two, the task needed a little more creativity.

We created Sitemap2XML for IIS 7 and above. It is comprised of 2 files, an .EXE (Sitemap2XML.exe) and a configuration file (Sitemap2XML_Config.txt). The program connects to the website’s sitemap.axd file specified in the configuration file and appends a list of additional URL’s to the end, then writes that out to a specified file, usually sitemap.xml.

Here is a sample of the configuration file:

   1: ; URL is the actual URL of the sitemap file (usually axd)

   2: url=http://mysite.com/sitemap.axd

   3: ; outputfile (optional) determines where the results of this program are written

   4: ; Default is Sitemap2XML_OUT.xml

   5: outputfile=c:\inetpub\wwwroot\mysite\sitemap.xml

   6: ; changefreq (optional) determines how often you want to specify changes to the page

   7: changefreq=monthly

   8: ; lastmod (optional) specify a date or use "_Today" to use today's date 

   9: lastmod=_Today

  10: ; addpage: include all additional pages that will be added to the output file

  11: addpage=http://mysite.com/page1.html

  12: addpage=http://mysite.com/page2.html

To install the program on your IIS server:

• Unzip the contents to any directory.
• Modify the Sitemap2XML_Config.txt file. Be sure your output file is in your website’s path
• Run the program in a DOS window to test. the program creates a log in the running directory.

Now the sitemap.xml file includes BOTH sitemap.axd results plus our additional sites.

The best way to keep this file up to date is to add it to the scheduled tasks on your server. Now, when you add your site to the webmaster tools of Yahoo or Bing, specify the sitemap.xml file that the program creates. This file will include the output from sitemap.axd and the additional URL’s you specify in the configuration file.

Have you ever wondered how blog and other advertising sites create an unending stream of URL's that contain the title? For example, our blog uses a trick called URL Rewrite, an add-on for IIS7. With this tool, you use regular expressions to create a filter that parses the info for you and redirects it to another page that can use that data to fill in the blanks.

For example: You can have a bot / SEO friendly URL like

http://www.esourcedevelopment.com/BlogPosts/3548/Windows_7_upgrade_horrors

which will actually be rewritten as:

http://www.esourcedevelopment.com/ShowRealPost.aspx?id=3548?title=Windows_7_upgrade_horrors

The URL that IE and Firefox show in the browser address space is the same as the first one requested, but the page actually displayed is the second one.

Setting up IIS7 to handle URL Rewrite

• Go to IIS Manager
• Select “Default Web Site”
• In the Feature View click “URL Rewrite“
• In the “Actions” pane on right hand side click on “Add rules…”
• In the "Add Rules" dialog, select the "Blank Rule" and click "Ok"

Now you must define the actual rewrite rule. In the URL rewrite module, a rewrite rule is defined by specifying four required pieces of information:

• Name of the rule;
• Pattern to use for matching the URL string;
• Optional set of conditions;
• Action to perform if a pattern is matched and all conditions checks succeed.

Naming a rule
In the “Name” text box enter a name that will uniquely identify the rule, for example: ”Rewrite to article.aspx”.

Defining a pattern
In the “Pattern” text box enter the following string:

^blogposts/([0-9]+)/([_0-9a-z-]+)

This string is a regular expression that specifies that the pattern will match any URL string that meets the following conditions:

• Starts with the sequence of characters “blogposts/”.
• Contains one or more numeric characters after the first “/”.
• Contains one or more alphanumeric or “_” or “-” characters after the second “/”.

Notice that certain parts of the regular expression are within parentheses. These parentheses create capture groups, which can be later referenced in the rule by using back-references.

Defining an action
Since the rule that we are creating is supposed to rewrite the URL, choose the “Rewrite” action type that is listed in the “Action” group box. In the “Rewrite URL:” text box, enter the following string:

ShowRealPost.aspx?id={R:1}&title={R:2}

This string specifies the new value to which the input URL should be rewritten. Notice that for the values of the query string parameters we used {R:1} and {R:2}, which are back-references to the capture groups that were defined in the rule pattern by using parentheses.

Now your actual page can decipher the QueryString values for ID and / or for title to search your database and display the article in question.

The entire tutorial on this setting can be found at http://learn.iis.net/page.aspx/461/creating-rewrite-rules-for-the-url-rewrite-module/

This site features a lot of 'how-to' information on IIS and is invaluable for any web developer.