【问题标题】:How can I have a seamless code push (why does Page._fPageLayoutChanged matter)?如何进行无缝代码推送(为什么 Page._fPageLayoutChanged 很重要)?
【发布时间】:2012-04-06 03:54:13
【问题描述】:

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

设置:3 个 Windows 2008 IIS 7 框 - 1 个处于关闭节点,另外 2 个处于活动状态(具有共享配置),并且所有 3 个都位于 BigIP 后面。我的网站设置为 1 个 Web 应用程序,下面有多个 Web 应用程序,全部为 .NET 2.0。我们正在使用 stateserver 和一个 set machinekey 用于 viewstate。这种设置对我们来说相对较新,因为我们以前只有一台 live 机器,而且它不在 BigIP 后面。迁移到此设置的一个原因是无缝推送。

我在做什么:对其中一个网络应用程序进行代码更改。为此,我对 down 节点进行更改,然后测试更改,然后复制到 up 节点。

我遇到的情况取决于更改的代码部分。例如,我在 webconfig.xml 中更改了一个值。当最终用户回帖时,一切正常,因为他们使用了 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 似乎无法正确连接它们)?是否有可能解决这个问题?

【问题讨论】:

    标签: c# .net iis-7 push ispostback


    【解决方案1】:

    许多大型网站都会不断部署更新。亚马逊是其中最著名的公司之一。看看这个幻灯片Continuous deployment

    一种方法是允许所有版本的代码同时运行,并根据“应该由版本 1.2.3.4 处理”cookie 等信息来路由请求来决定哪个版本应该处理请求。

    另一种方法是将向后兼容性内置到代码中。难以维护,但所需的基础设施要少得多 - 一次性的情况下还可以。

    【讨论】:

    • 感谢您的帮助(我浏览了所有幻灯片),但我需要一些有关如何在 .NET 中解决此问题的内容。并不是说代码不一定向后兼容……而是恕我直言,.NET 通过错误地标记属性来错误地对待 POST。
    猜你喜欢
    • 1970-01-01
    • 2016-11-23
    • 2023-03-22
    • 2021-10-05
    • 1970-01-01
    • 1970-01-01
    • 2018-02-01
    • 2013-01-12
    • 1970-01-01
    相关资源
    最近更新 更多