Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Background

I have recently developed a MVC application for a client and they would like to host it, along with a few other apps on the same server.

I am more of a developer than a server admin, but my instinct was to set up a new site in IIS with it's own sub-domain binding.

The client, however, would like to instead create a virtual directory in the default site that points to the application. So, for example, you would have:

COMPANY.COM/APP1 and COMPANY.COM/APP2

Rather than:

APP1.COMPANY.COM and APP2.COMPANY.COM

This did work; however, it conflicted with relative URLs in standard HTTP markup, a problem that was quickly resolved.

Question

Is it better to host multiple web apps on the same server as separate sites or as virtual directories within the default website? Are there any pitfalls with the virtual directory approach?

I am not judging the virtual directory approach, it is just new to me and I want to ensure that it won't cause problems now or in the future.

share|improve this question
    
I have the same question as OP. I currently use one site per application because it allows me to start and stop the individual websites. However, we don't have DNS set up to allows us to use host headers, so each website has to run on a different port. This makes for unfriendly URLs. VDs under Default Web Site would allow for friendly URLs at the cost of granularity. –  Walter Stabosz Dec 13 '12 at 17:18
add comment

2 Answers 2

I have always tried to stick to individual sites for applications. You get much more control over everything and if you're running ASP.NET you don't run into web.config cascading issues that are easy to hit. Plus you have finer grained control over application pools and actually being able to watch the performance of each individual application. This is all preference.

Regardless, probably the best answer is that you apply bindings at the website level and NOT the application level. So if each app needs its own URL or SSL as opposed to non-SSL you really do have to look at individual sites.

Plus as you mention you almost have to program with the deployment mechanism in mind. As any use of relative URLs breaks lots of stuff.

Lastly: why don't they want to use sub-domains? It provides nice clean RESTfulish separation of resources if you ask me.

share|improve this answer
add comment

I'd say it depends... Are the applications very similar to one another in that you could be comfortable making a single change at the higher level that would cascade down to each virtual directory that would not impact the functionality of any single app? If you have a separate site for each app then you will need to separately manage each site's settings (Certs, IPs, ports, etc), which could be a headache if there are a lot of them, but they are totally independent sites so a setting would not affect another app. The real work is done by the worker process/App Pool so in either setup you could share the same app pool for multiple apps or have a separate one for each app.

  • separate sites = much more granular control over the app and how to connect to it at the cost of more maintenance for each site
  • virtual directories = easier to manage if they are all very similar, but you could run into configuration issues if the apps have conflicting requirements
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.