resolving urls to some other url for development purposes - url-rewriting

Question

I am working with both asp and asp.net pages together. I wanted to host the application in my local iis (v5.1) but later learned about iisexpress suits my needs. But irrespective of whether I use iis 5.1 or iis express I seem to have an issue.
The asp page which I work with refers to static resources (css, javascript, etc) which reside in a different virtual directory. For e.g. a css file include would look like this.
<link rel="stylesheet" href="/common/include/style/css.css"/>
If such a thing is supposed to run from the test environment then the above url would resolve to:
http://testing/common/include/style/css.css
This is in contrast where my main application would reside. That would look something like:
http://testing/myapp/default.aspx
Now if I run iisexpress in say port 8082, and there is an inbound request like:
http://localhost:8082/common/inlcude/style/css.css
it will hit a 404 error. Is it possible to instruct iss or iis express to resolve such url (which begin with /common/...) to say http://testing/common/...
Update (May 31st 2011, 7.04 PM IST):
Been doing some research on what url rewriting is, and from the examples I have come to understand a few things. I am not sure if what I want is url re-writing, per se. Again taking the iisexpress analogy, I know there will be an inbound request uri like:
http://localhost:8082/common/inlcude/style/css.css
But I want this to be actually served by the following uri:
http://testing/common/include/style/css.css
The former uri doesn't exist in the folder which I have virtualized using iisexpress.
Do I need url re-writing here?
Further, in ASP, I have include lines like:
<!-- #include virtual="/common/include/classes/utils.asp" -->
Even these things are supposed to be resolved to their corresponding http://testing/... counterparts.
ps: I am doing all this is iis 5.1

Answer 1

In ASP.NET 2.0 onwards you can use the tilde operator (~) which is used to specify where your application is rooted. For example:
<link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
Would produce a relative url:
<link href="Styles/Site.css" rel="stylesheet" type="text/css" />
This works fine for ASP.NET pages.
Classic ASP and static HTML pages are a different story and one or more of the following mechanisms would have to be used:
Make everything relative. If you have a page or ASP script in the root of the site, instead of specifying /common/include/... specify common/include/.... If you have a page or ASP script in a subfolder the you'd reference your CSS by way of ../common/include/..., i.e. parent paths. The deeper the folder structure the more ../ parent paths you have so managing these relative paths can get messy. Also, although not common these days, some shared hosted servers disallow parent paths.
Prefix your CSS paths with a variable containing a path prefix. For example:
<link rel="stylesheet" href="<%=Session("RootPath")%>/common/include/style/css.css"/>
In production you'd globally set the session value RootPath to /MyApp, but for testing leave as an empty string. You could do this in Session_OnStart in your global.asa. You could also use an application wide value Application("RootPath") instead. This would only work for ASP pages.
URL Rewriting - if you have static HTML pages then URL rewriting can come to the rescue. You would rewrite the absolute url's which work on your dev PC to the path used on the production server. So basically every time you see a href="/common/... you'd rewrite to href="/myapp/common/.... IIS6 doesn't support rewriting out of the box, you'd need a third party tool such as Iconics IRF or HeliconTech's ISAPI_Rewrite3. IIS 7.x does support URL rewriting through the URLRewrite Module 2.0.