Should you code ASP.NET sites so they can live in a VDIR?

Question

Back in the days before Visual Studio Web Server we would host our local dev inside IIS. If you have a workstation version of IIS that means only 1 website. What if you are working on several websites. Easy: create them in VDIRs, e.g. http://localhost/ProjectA, http://localhost/ProjectB.

Living in a VDIR doesn't sound so hard. Make sure all your images/CSS/links are relative paths, use the "~" a lot. Sounds like a good practise. Hardcoding images etc so they only work when the application is served from "/" sounds like a bad practise.

There are some nuances anywhere you have to build a link (mostly not common scenarios):

• eg; PROD: http://prodserver.com/images/up.jpg -> DEV: http://localhost/ProjectA/images/up.jpg
• links / images in emails
• flash/javascript/silverlight requests data from the server which contains links to images
• The full link to the a PayPal IPN (the page paypal POSTs their response too)

So.. Are you doing this? Advantages / disadvantages? Any other gotchas I've missed?

Answer 1

I always avoid hardcoded paths, URLs, etc. unless there's a specific reason to do otherwise. Things inevitably change, and there's always the jump from your dev site to production.

The part that is usually the biggest nuisance would be in reusable client behaviors that need to reference other paths, and themselves can be reused in pages across the application's directory structure.

I like the idea handler that responds to "globalvars.ashx" (or something like that; there are many ways to handle this) which dynamically emits (and allows caching) properties regarding the global application properties.

Say the handler responsible for globalvars.ashx writes the result of something like this:

String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);

Your JS behaviors could theoretically reference that property object at any point via ApplicationProperties.RootPath.

Answer 2

In short, yes. The disadvantages of not doing so outweigh the benefits. I actually think your first two points can also be mostly mitigated from using app-relative paths ("~"), but nevertheless, some scenarios such as "integration-level" ones (like PayPal) may indeed prove tricky.

But at the end of the day, if you need to host your app in a virtual directory you are virtually guaranteed problems if you haven't coded your app to be vdir-friendly from the get go. I know I have.

Some background/context: My current production environment at work is almost always a virtual directory anyway, so I do this by necessity. And I've never had a problem when an application was created as a root-level website. This certainly wouldn't be the case if it was the other way around.