ClickOnce. Инкриминтирование версии
1. допустим инкрементировать последнюю цифру, хранить в самом manifest-e
2. писать в последнюю цифру число секунд от сотворения IT-мира, ничего не хранить
2. писать в последнюю цифру число секунд от сотворения IT-мира, ничего не хранить
1. допустим инкрементировать последнюю цифру, хранить в самом manifest-eнужно обратиться к манифесту предыдущей версии. Если с предыдущей версией что-нибудь сделают: удалят, переместят и т.п., будут проблемы, причем очень неприятные, связанные с кешом на клиентах.
2. писать в последнюю цифру число секунд от сотворения IT-мира, ничего не хранить
это не надежно
Есть идея использовать GUID
, версия как раз состоит из 4-х 32-разрядных целых, GUID 128-битный.1. В on-line режиме ClickOnce-а (насколько я понял) возрастание версии необязательно.
2. В реальности возникли проблемы, максимальный номер версии 31-бит. Видимо используется знаковый int, хотя в документации говорится о беззнаковом 32-битовом целом. Но к счастью, в GUID-е тоже есть 4-е лишних бита — номер версии алгоритма генерации, а для Windows начиная с 2000 он один и тот же (это не очень существенное ограничение на машину, с которой деплоится приложение).
для Windows начиная с 2000ИМХО, это ограничение тоже можно снять, если самим генерить GUID, например, как здесь
http://msdn2.microsoft.com/en-us/library/Aa446557.aspx
с заменой coredll.dll на advapi32.dll
2. писать в последнюю цифру число секунд от сотворения IT-мира, ничего не хранить> это не надежно
почему не надежно?
> Есть идея использовать GUID
это тоже самое, что использовать время от сотворения IT-мира, т.к. GUID напрямую генерится на основе времени
это тоже самое, что использовать время от сотворения IT-мира, т.к. GUID напрямую генерится на основе временинет, в guid входит больше параметров
on Windows CE:
Thread and kernel switches
The current process identifier
The current thread identifier
Ticks since boot
Current time
Memory information
Object store statistics
почему не надежно?на разных компах время может идти по-разному, как правильно заметил товарищ Шурик
> на разных компах время может идти по-разному, как правильно заметил товарищ Шурик
и что?
Clickonce подписывается всегда на одном и том же компьютере, который в том числе можно еще и жестко синхронизировать на мировое время
и что?
Clickonce подписывается всегда на одном и том же компьютере, который в том числе можно еще и жестко синхронизировать на мировое время
и что?Существуют различные способы делать билды. Некоторые из способов не завязываются на один компьютер.
Clickonce подписывается всегда на одном и том же компьютере, который в том числе можно еще и жестко синхронизировать на мировое время
какое отношение имеют билды к "Они должны поменять ConnectionString и переподписать манифесты."?
Clickonce подписывается всегда на одном и том же компьютере, который в том числе можно еще и жестко синхронизировать на мировое времяи как ты себе это представляешь? требовать от IT-подразделения заказчика подписывать ClickOnce строго на одном компьютере? да еще настраивать на нем синхронизацию. Это очень неудобно.
как ты себе представляешь влияние разницы времени между компьютерами на процесс подписывания?
они будут подписывать через каждые дцать секунд?
они будут подписывать через каждые дцать секунд?
они будут подписывать через каждые дцать секунд?реально разница во времени может быть 5-10 мин. Поэтому теоретически совпадение количества секунд возможно. Вот например такая ситуация. Задиплоили с одной ConnectionString, через 5 мин выяснилось, что ошиблись в ConnectionString, в это время админ оказался на другой машине и снова задиплоил уже с другой машины. Конечно, это несколько надуманный вариант
> в это время админ оказался на другой машине и снова задиплоил уже с другой машины
далее проверит, увидет что все сломаль, покурит и задиплоит еще раз
далее проверит, увидет что все сломаль, покурит и задиплоит еще раз
далее проверит, увидет что все сломаль, покурит и задиплоит еще раз1. он это может не увидит, это зависит от состояния ClickOnce кеша на конкретной машине
2. он перепроверит коннекшен стринг, увидит что он правильный и заасанит нам багу
подписывать он с помощью чего будет? с помощью сервиса с веб-мордой?
подписывать он с помощью чего будет? с помощью сервиса с веб-мордой?пока консольное приложение с настроичным файлом
Все оказалось печальнее, каждая из 4-х компонент версии не может быть больше 65536 (а в доке написано 32-бита
). Остановились на варианте генерации 8-ми случайных байт с помощью CryptRandom. Кроме того в конфиг приложения генериться guid. При запуске приложения идет обращение к шарной папке деплоимента, сравниваются версии и guid-ы, если версии совпадают, а guid-ы нет, просим пользователя очистить ClickOnce кэш или администратора передиплоить приложение, но наедимся такого не случится Оставить комментарий
6yrop
есть двухзвенное WinForms-приложение. Развертывается в локальной сети. Хочется использовать ClickOnce. Исходники лежат в TFS-е, приложение собираем мы. А вот развертываем у заказчика не мы. Те кто развертывает доступа к TFS-у не имеют. Они должны поменять ConnectionString и переподписать манифесты. Вопрос, какую версию ставить после изменения ConnectionString? т.е. как эту версию инкриментировать и где хранить?