8

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.

2
  • 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. Dec 13, 2012 at 17:18
  • Huh? If it was truly relative URLs it would not have mattered if the application was in its own site, in a virtual directory, or in another sites directory several levels deep.
    – Ants
    May 6, 2016 at 1:05

2 Answers 2

5

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.

1
  • Nice RESTful separation of resources that can't be easily shared without configuring CORS or Jsonp.... Dec 12, 2014 at 13:33
1

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.

  • Applications on separate sites = much more granular control over the app and how to connect to it at the cost of more maintenance for each site
  • Applications on same site = easier to manage if they are all very similar, but you could run into configuration issues if the apps have conflicting requirements

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .