我们有一个IIS 7.5服务器pipe理我们的托pipe产品。 每一代产品都有自己的AppPool和自己的网站。 每一代都绑定到thegeneration.oursite.com，加上一个幸运的网站获得默认的绑定（这显然是客户实际打的）。 当我们准备切换到新的站点时，我们有一个工具，试图将默认绑定从旧一代切换到新的一代。 这种模式是：
到现在为止还挺好。 我们的代码很简单，效果很好。
好吧，差不多。 不pipe我们做什么，不pipe我们如何devise结构， IIS总是closures新的默认绑定，抱怨现在有两个默认绑定的站点。 无论我们使用Microsoft.Web.Administration程序集还是编辑applicationHost.config发生这种情况。 值得注意的是，在冲突警告后100％的时间内手动启动站点， applicationHost.config和assembly接口都不会在任何时候显示两个默认绑定的站点。
当我们交换默认绑定时，我们如何保持IIS 7.5closures？ 有没有办法做到这一点？
编辑 ：我被要求澄清我的意思是一个例子，所以我会走过一个项目的实际升级，我们这样pipe理，窑。
所以我们假设我们从两个活跃的窑炉开始：窑Kiln1.0和窑Kiln2.0 。 这意味着我有AppPools这些名称和这些名称的网站。 基本上客户在Kiln1.0 ; 只有我们的testing人员和testing用户在Kiln2.0 。 窑的账户属于子域，所以为了达到这个目的， Kiln2.0站点绑定了例如*:80:foo.kilnhg.com ， *:80:bar.kilnhg.com等，而Kiln1.0站点拥有绑定*:80:*这样任何不明确在testing世代的人都在新一代。
当我们想把每个人升级到Kiln2.0 ，我们要删除Kiln2.0的*:80:*绑定，并在Kiln1.0创build它。 我遇到的问题是， 每一种方法都会closuresKiln2.0 ，IIS声称绑定是重复的。 这就是导致问题的那个特定的绑定。
这听起来像你可能是IISconfiguration更新延迟的受害者。
通常情况下，这可以通过减less步骤数来避免（例如，为什么清除然后重新build立绑定？只需一次replace它们然后提交更改）或添加等待状态。
是的，等待状态。 在这个batch file/脚本/程序的中间{hibernate10秒}可能也会起作用。