We have a fleet of IIS 7.5 servers that manage our hosted product. Each generation of the product gets its own AppPool and its own site. Every generation is bound to thegeneration.oursite.com, plus one lucky website gets the default binding (which is the one customers actually hit, obviously). When we are ready to switch to the new site, we have a tool that attempts to switch the default binding from the old generation to the new one. The pattern for this is:
- Clear the bindings on all websites.
- Reestablish the custom bindings on all websites
- Set the default binding to the new active generation.
So far, so good. Our code to do this is simple and works great.
Well, almost. Here's the thing: no matter what we do, no matter how we try to structure things, IIS always shuts down the new default binding, complaining that there are now two sites with default bindings. This happens no matter whether we use the
Microsoft.Web.Administration assembly or edit
applicationHost.config. Notably, manually starting the site after the conflict warning works great, 100% of the time, and neither
applicationHost.config nor the assembly interface actually show two sites with the default binding at any point.
How can we keep IIS 7.5 from shutting down when we swap default bindings? Is there really no way to do this?
EDIT: I was asked to clarify what I meant wth an example, so I'll walk through an actual upgrade of one project we're managing this way, Kiln.
So let's say we start off with two generations of Kiln that are active:
Kiln2.0. This means I have AppPools with those names and sites with those names. Basically customers are on
Kiln1.0; only our testers and beta users are on
Kiln2.0. Kiln accounts belong to subdomains, so to achieve this, the
Kiln2.0 site has bindings for e.g.
*:80:bar.kilnhg.com, etc., and
Kiln1.0 site has the binding
*:80:* so that anyone who's not explicitly on the testing generation is on the new generation.
When we want to upgrade everyone to
Kiln2.0, we want to delete the
*:80:* binding on
Kiln1.0 and create it on
Kiln2.0. The issue I'm having is that every single way to do that shuts down
Kiln2.0, with IIS claiming that the binding is duplicated. It's that particular binding that's causing the issue.