如何进行无缝代码推送(为什么Page_fPageLayoutChanged很重要)

我们有一个无法解决的问题：如何在白天推送代码而不中断最终用户。我是一名开发人员，与我的系统部门协同工作。

安装程序：3个Windows 2008 IIS 7盒子-1个是关闭节点，另外2个是活动的（使用共享配置），所有3个都在BigIP后面。我的网站设置为一个web应用程序，下面有多个web应用软件，全部为.NET 2.0。我们正在使用stateserver，并为viewstate设置了machinekey。这种设置对我们来说相对较新，因为我们以前只有一台实时机器，而且它并不落后于BigIP。迁移到这种设置的一个原因是无缝推送。

我正在做的是：对其中一个网络应用程序进行代码更改。我通过对向下节点进行更改，然后测试更改，然后复制到向上节点来实现这一点。

我所经历的取决于代码的哪一部分发生了变化。例如，我更改了webconfig中的一个值。当最终用户返回时，一切都很好，因为他们在webconfig中使用了新值。我们非常喜欢这个！我还能够以某些无缝的方式更改dll代码（更改后端的逻辑）。

然而，真正困扰我们的问题是：我给表单添加了一个新标签。一旦我添加了新标签，.Net的行为就像是用户第一次加载表单，但他们所有的视图状态都被保留了。我特别将其追溯到Page.IsPostBack属性，并进一步通过反射将其追踪到_fPageLayoutChanged_当我通过推送将新内容添加到表单时，fPageLayoutChanged=true。最终用户的体验是，他们的内容仍然存在b/c视图状态仍然存在，但我在第一次加载时所做的操作都被触发了，他们试图执行的事件没有被连接起来。例如，如果他们按下按钮保存笔记，笔记仍在屏幕上，但按钮单击事件没有启动，因此他们的笔记不会保存。根据页面体系结构的不同，有时这与用户需要再次单击保存一样温和，但也可能与代码擦除他们所做的一样糟糕。b/c这取决于IsPostBack来激发从数据库加载注释的代码。

以下是来自网络的IsPostBack的代码（这是伤害我们的最后一部分）：

public bool IsPostBack {
    get {
        if (_requestValueCollection == null)
            return false; 
        // Treat it as postback if the page is created thru cross page postback. 
        if (_isCrossPagePostBack) 
            return true;
        // Don't treat it as a postback if the page is posted from cross page
        if (_pageFlags[isCrossPagePostRequest])
            return false;
        // If we're in a Transfer/Execute, never treat as postback (ASURT 121000)
        // Unless we are being transfered back to the original page, in which case 
        // it is ok to treat it as a postback (VSWhidbey 117747) 
        // Note that Context.Handler could be null (VSWhidbey 159775)
        if (Context.ServerExecuteDepth > 0 && 
            (Context.Handler == null || GetType() != Context.Handler.GetType())) {
            return false;
        }
        // If the page control layout has changed, pretend that we are in
        // a non-postback situation. 
        return !_fPageLayoutChanged; 
    }
} 

最后一行的评论让我很难过，b/c它没有解释他们为什么做出这个决定。

此外，我不敢相信，我们是唯一一个试图在白天推送代码而不干扰最终用户的人，但却遭到了阻挠。我们不知所措。是否需要更改IIS设置？重新设计我们的代码，使其不依赖于IsPostBack属性（但事件仍然不会触发，因为当IsPostBack为false时，.NET似乎无法正确连接它们）？绕过这一点可能吗？