У нас есть проблема, которую мы не можем решить: как отправить код в течение дня без прерывания работы конечного пользователя.Я разработчик, и я работаю в тандеме с моим системным отделом.
Установка: 3 блока Windows 2008 IIS 7 - 1 не работает, 2 других находятся в рабочем состоянии (с общей конфигурацией), ивсе 3 позади BigIP.Мой сайт настроен как 1 веб-приложение с несколькими веб-приложениями, все .NET 2.0.Мы используем сервер состояний с установленным автоматическим ключом для viewstate.Эта установка является относительно новой для нас, так как ранее у нас была только одна живая машина, и она не была за BigIP.Одна из причин перехода к этой настройке была для плавных нажатий.
Что я делаю: внесение изменения в код одного из веб-приложений.Я делаю это, внося изменения в нисходящий узел, затем проверяя изменения и затем реплицируя на нисходящие узлы.
То, что я испытываю, зависит от того, какая часть кода изменяется.Например, я изменяю значение в webconfig.Когда конечный пользователь отправляет обратно, все работает хорошо, поскольку они используют новое значение в webconfig.Нам это очень нравится!Я также могу изменять dll-код определенным образом, что также беспроблемно (изменение логики на бэкенде).
Однако проблема, которая нас действительно мучает, заключается в следующем: я добавляю новый ярлык в форму.Как только я это сделаю, .Net действует так, как будто пользователь впервые загружает форму, но все его представления сохраняются.Я специально проследил это до свойства Page.IsPostBack, а затем, с помощью отражения, отследил до _fPageLayoutChanged._fPageLayoutChanged = true, когда я добавляю новое содержимое в форму с помощью push.Опыт конечного пользователя заключается в том, что его контент все еще там, поскольку b / c viewstate все еще там, но все действия, которые я выполняю при первой загрузке, выполняются, и событие, которое они пытались выполнить, не было подключено.Например, если они нажали кнопку, чтобы сохранить свои заметки, заметки все еще находятся на экране, но событие нажатия кнопки не сработало, и, следовательно, их заметки не сохраняются.В зависимости от архитектуры страницы, иногда это настолько мягко, что пользователю нужно снова нажать «Сохранить», но может быть так же плохо, как и код, уничтожающий то, что он сделал, потому что 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;
}
}
Комментарий к последней строке убивает меня, потому что это не такНе могу объяснить, почему они приняли такое решение.
Кроме того, я не могу поверить, что мы единственные, кто пытался продвигать код в течение дня без перерыва для наших конечных пользователей и был сорван этим.Мы в недоумении, что делать.Нужно ли менять настройки IIS?Реорганизовать наш код так, чтобы он не зависел от свойства IsPostBack (но тогда события все равно не будут срабатывать, поскольку .NET, похоже, неправильно их подключает, когда IsPostBack имеет значение false)?Возможно ли вообще обойти это?