I'm having a problem installing a web application into IIS 7.5. I'm using a standard web application installer build with VS2010, but when I install the application I want it to be placed at the root of the site (instead of inside a virtual folder). Here's a little diagram of the setup:

  • C:\inetpub\wwwroot\
    • static <--- IIS default folder
    • app1
    • app2
    • app3
    • ....

Each of the apps has their own app pool. The static folder uses the main application pool which is used by the default for the entire site.

If I run the installer and leave the virtual directory field blank, everything appears to work fine. The problem is that somehow all of my other applications get moved into the default app pool and ultimately break because the permissions are relatively restrictive.

Does anyone know of a way around this? I don't want the users to have to enter .../static/... in the URL for the site, so simply installing to a virtual directory the "normal" way won't work.


-- Dan


After a lot of investigation, I think there's either a bug in the web application installer or in IIS itself. Because I'm stuck with the web application installers for the time being, here's how I got around it:

  1. Moved IIS default folder to C:\inetpub\wwwroot (this is the default anyway)
  2. Set the applicaiton pools for the whole site and static to be the same
    1. IIS won't let you do URL rewriting across application pools. If that is a concern -- you'd have to setup a full blown reverse proxy.
  3. Installed the IIS URL Rewrite Plugin
  4. Created a new URL rewrite rule with the match pattern (/*)(.*)
  5. Added conditions to the rule as follows (match all)
    1. Input {URL} Does not match ^(/*)app1/(.*)
    2. Input {URL} Does not match ^(/*)app2/(.*)
    3. ... One for every app ... (yeah, it's a pain)
  6. Set the action to Rewrite to /static/{R:2}

In my case I didn't need any outbound rules (ie. I didn't need a whole reverse proxy) because my apps return valid URLs.

The nice thing about this solution is that it is totoally transparent to the user, and any existing links that begin with / (ie. ...a href="/images/file.jpg"...) will still work because when the end user requests /images/file.jpg the URL will be rewritten internally to /static/images/file.jpg.

The main downside is that I have to keep the list of match patterns up to date with all the app pools. But in my case that's not a big deal. I could actually automate the injection of new pattern strings in the web.config file -- but it's not a big deal in my case.

One other downside is that the user could see links to /static/images/... in the source code -- but I don't really care about that.

So - hopefully this will help someone in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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