We recently upgraded the IIS 7 servers with version 2.0 of the URL rewrite module.

I have to be honest – generally speaking, SEO & URL rewriting is not a topic that I often (ever) think about. The reality is, no matter how you write your URLs, if your site only has a handful of visitors, the format of your URLs is not going to matter. Your time would be much better spent improving your site, making it more useful and popular. So why spend time and energy on such a topic when there is so much other stuff to do? I think most people share this opinion. But that’s what makes this new version so interesting to me.

Yes, this is indeed a major upgrade, and the feature list is lengthy. But what “The rest of us” will be happy to know is that Microsoft has included templates that make this process much easier. These are essentially tiny wizards that allow you to plug in a couple values and let the tool deal with the rest.

The first thing you need to do is get the IIS 7 Manager add-in to control the service.  When you connect to the server using IIS 7 Manager you will be greeted with a window asking if you would like to install the add-in (if you have the old module already, you will be asked to upgrade when you connect).

Now, let’s try a few things and see how easy this is. Let’s assume that you want to redirect requests for YourHostedDomainName.com to www.YourHostedDomainName.com

• In IIS 7 Manager, navigate to the URL Rewrite section
• Click Add Rule on the right hand side
• Click the canonical domain name template
• Enter your domain name, including the www

That’s it. Done.

Next, let’s work on making some user-friendly URLs. Let’s assume for a moment that we have an application that generates URLs in the following manner:

http://www.YourHostedDomainName.com/application/default.aspx?id=123

And we wanted to rewrite the URL as:

http://www.YourHostedDomainName.com/123

• In IIS 7 Manager, navigate to the URL Rewrite section
• Click Add Rule on the right side
• Click User-Friendly URL

You will notice that you have an option for how you want the URL to be rewritten. The best part is that it is generating the regular expressions and corresponding inbound/outbound rules required to perform the task automatically.

Another cool feature is that by clicking the Create corresponding outbound rewrite rule check box, any links with an unfriendly URL within your pages will also be rewritten.

So for example, let’s assume you had a page with the following link:

<a href=”Test”>http://www.YourHostedDomainName.com/application/default.aspx?id=123″>Test Link</a>

This link would automatically be rewritten on the fly and served as:

http://www.YourHostedDomainName.com/123

These two scenarios are what we get asked about most commonly. You can see how easily URL Rewrite 2.0 addresses them. And we have not even scratched the surface. This release is extremely deep and can be used to perform a multitude of tasks. If you want to work with some of the more complex operations, I suggest you visit the learning section of the IIS site.

Some of the key points that stand out are:

Access to server variables and http headers. Server variables and HTTP headers provide additional information about current HTTP request. This information can be used to make rewriting decisions or to compose the output URL.

Various rule actions. Instead of rewriting a URL, a rule may perform other actions, such as issue an HTTP redirect, abort the request, or send a custom status code to HTTP client.

Failed Request Tracing support. IIS 7 Failed Request Tracing can be used to troubleshoot errors related to URL rewriting.

GUI tool for importing of mod_rewrite rules. URL rewrite module includes a GUI tool for converting rewrite rules from mod_rewrite format into an IIS format.

Michael Ossou
Technical Support

We have noticed an increase in interest from our customers in incorporating Microsoft Excel automation tasks into their ASP.NET applications. As OWC is a thing of the past, I’m going to concentrate on interoperability issues and a solution to the problem (more on that later).

For the purposes of these examples, all we are going to do is create a document.  Populating cells and doing other tasks, while easy enough, would detract from the focus of this post.

The scenario I outline below is rather common. Let’s start with the initial creation of the application on a developer’s box with Microsoft Office installed on it.

using Microsoft.Office.Interop.Excel;

protected void Button1_Click(object sender, EventArgs e)
{

Microsoft.Office.Interop.Excel.Application myApp = new Microsoft.Office.Interop.Excel.Application();

myApp.Visible = true;
Workbook myWorkBook = myApp.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);
Worksheet myWorkSheet = (Worksheet)myWorkBook.Worksheets[1];

}

While this would indeed work on the developer’s machine, once uploaded to the server, an error such as the following would be thrown:

Could not load file or assembly 'Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.

Naturally, they would then assume they needed to upload the Microsoft.Office.Interop.Excel.dll file to the bin directory. However this would lead to another error, similar to:

Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046}
failed due to the following error: 80040154.

If it runs on the developer’s machine, why doesn’t it run on the server?

First, some background. Interoperability is what allows .NET (the CLR specifically) to leverage unmanaged libraries. Essentially it works as a proxy. In this case, we are interested in programmatically accessing the functionality of the Excel COM object.

The application itself isn’t concerned with the COM object, only the interop assembly.  This is the reason for the first error. Upon uploading the interop to the bin directory, the application will at least then compile, but attempting to work with the interop will result in the second error.  This is because unlike the developer’s station, the COM object isn’t present on the server (Office cannot be installed on the servers – licensing, security, and performance issues prevent this).

Ok so what’s the solution? Well, as it turns out, there is a project called ExcelPackage that will allow us to work with Excel documents without having to worry about Office, Interops, OWC, or anything else! This is due to the use of XML file formats. The only downside being it won’t help you when working with ancient versions of Excel. So let’s get to it.

• First, go get ExcelPackage
• Next unzip it and place the .dll in your applications bin directory
• Create an .xlsx document in Excel and put it in your applications root (for this sample). This is the template we are going to use to create our document from I’ve called mine Book1.xlsx
• Create a reference in Visual Studio for the ExcelPackage.dll
• Build your application and upload!

public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{

}
protected void Button1_Click(object sender, EventArgs e)
 {
FileInfo myTemplate = new FileInfo(@"e:\web\domain\htdocs\APP\book1.xlsx");
FileInfo myExcelFile = new FileInfo(@"e:\web\domain\htdocs\APP\NewXclFile.xlsx");

using (ExcelPackage xlPackage = new ExcelPackage(myExcelFile, myTemplate));

Response.Redirect(@”~/NewXclFile.xlsx”);

}
}

Michael Ossou