Home/ Questions/Q 7912189
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T13:32:10+00:00

Quite a few years ago, I remember that I struggled with a multiple site

  • 0

Quite a few years ago, I remember that I struggled with a multiple site under one domain situation, where one of the sites was placed in the root.

At the time I read an authoritative post that clearly explained to me why this was a bad idea, what I remember is the cascading web.config issue being the main reason (forcing you to undeclare conflicting references in child projects that are essentially alien to that project). Henceforth I’ve always deployed any website in its own virtual path, using a single redirect in the root to point to the default website.

I can’t seem to find that authoritative reference anymore and deployment considerations may have changed since then.

What are the pros and more likely, the cons for this scenario? I’m asking because a company I work with frowns on separating the deployments this way and I don’t think that’s a good idea.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Short answer : isolation. IMO the benefits to host different web site/web applications without isolating them are pointless.

    Long answer :

    Pros :

    • Using a single port without specific bindings (ie. aliases) : if you
      don’t have access to website bindings, its usefull
    • Rapid-deployment and dynamic web site creation : you can create a new
      subsite without declaring it on the IIS side
    • Sharing settings : apply web site base settings to all subsites
      (documents, mime types etc…)

    Cons :

    • Application pool isolation : no identity isolation, no worker process
      isolation, no failure/recovery isolation, etc… (time out, memory limit etc…)

    • AppDomain or lifetime isolation : you’ll have to take care of your website AppDomains. If you share the same AppDomain, you’ll share the same life cycle : if the
      AppDomain is unloaded, all the websites under this AppDomain will go down and reloaded (ie. if you touch an AppDomain web.config)

    • Architecture isolation : some web application development need some
      tunning on the IIS side, if you tune your IIS pool or website just
      for one app, its an impact for all the sites. I think about 32-bits and 64-bits setting or wildcard mapping for example.

    • Code and security isolation : application running in the same worker process and/or AppDomain are less protected against cross-app access/hacks/attacks. You’ll have to be more vigilant to ensure that informations from an app cannot be read by another.

    • Audit : it could be more difficult to audit the web sites activity and failure.

    Web application isolation has always be a goal on mutualised environments to protect applications from each other.

    Since IIS 7, application pool isolation go further with the “application pool identity” : http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx

    I found this article too : http://searchsecurity.techtarget.com/tip/Web-application-isolation.

    You should look at SharePoint site collections architecture too. Here’s the idea : http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx.

    • 0