Обычно существует два метода обновления приложения: один — уведомить пользователя (например, отправить электронное письмо) и попросить пользователя загрузить обновленную программу с назначенного адреса веб-сайта, другой — передать ответственность за обновление с пользователя на пользователя; Само приложение вместо того, чтобы пользователь получал и устанавливал обновления программного обеспечения, само клиентское приложение отвечает за загрузку и установку обновлений с известного сервера. Единственное вмешательство, которое должен сделать пользователь, — это решить, хотят ли они устанавливать новые обновления сейчас или. позже. Очевидно, что последний более дружелюбен, чем первый. Теперь вы можете увидеть реальные продукты, напоминающие последний подход, такие как Windows XP и Microsoft Money. Компонент обновления приложений .NET, представленный в этой статье, может предоставлять аналогичную функциональность.
1. Знакомство с компонентом обновления приложений .NET.
Компонент обновления приложений .NET AppUpdater разработан с использованием платформы .NET. Хотя AppUpdater не является продуктом Microsoft, при добавлении компонента на панель инструментов VS.NET вы можете перетаскивать его с панели инструментов в свое приложение так же, как и при использовании других компонентов. После установки некоторых свойств (например, местоположения). и частота получения обновлений и т. д.), ваше клиентское приложение может иметь функцию автоматического обновления.
2. Принцип работы
Чтобы глубоко понять принцип работы компонента обновления клиентского приложения .NET, необходимо внимательно изучить, что необходимо сделать для реализации обновления клиентского приложения. Первый шаг — проверить наличие обновления; при обнаружении обновления начать второй шаг — загрузить обновление, когда загрузка обновления завершится, перейти к последнему шагу — реализовать обновление;
(1) Проверьте наличие обновлений.
Как разработчик, вы должны сначала указать приложению, где проверять наличие обновлений. В противном случае не будет ли это похоже на поиск иголки в стоге сена? Во-вторых, определите, когда проверять наличие обновлений. Пользователь не может каждый раз запускать клиентскую программу, и она постоянно проверяет наличие обновлений в фоновом режиме. Какая трата ресурсов! И последняя важная вещь, которую следует решить, — это проверка наличия обновлений. Компонент обновления приложений .NET использует для связи HTTP, что позволяет клиентским приложениям выполнять обновления через брандмауэры. И адрес, необходимый для проверки обновлений, становится URL-адресом известного веб-сервера, и первая проблема успешно решается.
Компонент обновления приложения .NET генерирует поток на основе генерации компонента, который отвечает за проверку обновлений. Этот поток большую часть времени спит, но просыпается через заданные интервалы и выполняет проверку обновлений. Частота, с которой приложение проверяет наличие новых обновлений, зависит от приложения. Общие значения интервала между проверками обновлений обычно составляют от одного часа до нескольких дней. Этот базовый подход к опросу подходит не для каждой ситуации. Например, Microsoft Money проверяет наличие обновлений только тогда, когда пользователь об этом просит. В этом случае поток опроса обновлений можно отключить.
Проверка обновлений реализуется путем вызова метода CheckForUpdate() компонента обновления командой.
Существует несколько методов проверки обновлений:
Способ 1: Прямая проверка файлов. Используйте HTTP для сравнения отметки даты и времени последнего изменения серверного и клиентского приложений, чтобы убедиться в их согласованности. Если на сервере есть обновленный файл, клиент знает, что он может обновиться сам. То же самое справедливо и для веб-браузера, который знает, нужно ли ему повторно загрузить HTML-страницу или изображение или он может повторно использовать ранее загруженное. Когда новая версия приложения становится доступной, администратор просто копирует более новую версию поверх старой на веб-сервере. Проблема этого подхода в том, что обновление не происходит автоматически, поэтому существует вероятность сбоя. Например, если администратор обновляет версию приложения на веб-сервере, а клиент загружает версию до обновления, то на компьютере клиента будут некоторые файлы до обновления, а также некоторые файлы из новой версии. версия после обновления документа. По вышеуказанным причинам прямая проверка файлов на наличие обновлений не рекомендуется для критически важных приложений.
Способ 2: Явная проверка — используйте явный файл конфигурации на сервере. Действительный явный файл сервера для использования с компонентами обновления приложений .NET выглядит примерно так: ..
<VersionConfig>
＜Доступная версия＞1.0.0.0＜/Доступная версия＞
＜ApplicationUrl＞ http://localhost/demos/selfupdate/V1/ ＜/
URL-адрес приложения＞
</VersionConfig>
AvailableVersion указывает номер версии последней доступной сборки. Атрибут ApplicationURL указывает URL-адрес, по которому находится эта версия приложения. Когда администраторы хотят обновить клиентское приложение, они копируют новую версию приложения на веб-сервер и соответствующим образом изменяют явные файлы сервера. Клиент сам обнаружит, что явный файл сервера был изменен, и затем загрузит явный файл. Затем клиент сравнивает номер версии сборки, указанный в явном файле, с номером версии EXE-файла приложения. Если в явном файле сервера доступен более новый номер версии, приложение знает, что его необходимо обновить. Этот метод рекомендуется для большинства приложений.
Способ третий: проверка веб-службы XML. XML WebServices предоставляет более продвинутый метод проверки обновлений. Например, предположим, что вы хотите обновить набор ранних пользователей перед обновлением других пользователей. Если клиентское приложение вызывает веб-службу XML, чтобы проверить, доступно ли обновление, эта веб-служба XML также может запросить обновление для этого пользователя. и определить, является ли пользователь ранним пользователем. Если они являются ранними пользователями, веб-служба XML возвращает значение, указывающее, что обновления доступны. Если нет, веб-служба возвращает значение, указывающее, что обновление недоступно. Однако компонент обновления приложений .NET, представленный в этой статье, не обеспечивает прямую поддержку веб-службы XML.
Чтобы использовать веб-службу XML для проверки обновлений, сначала создайте веб-службу XML и перехватите событие OnCheckForUpdate. Это позволяет вам писать свои собственные проверки вместо проверок обновления потока опросчика. Событие OnCheckForUpdate имеет возвращаемое значение, указывающее, было ли обнаружено обновление.
(2) Загрузка обновлений.
Когда компонент обновления приложения .NET обнаруживает, что доступно новое обновление, он автоматически запускает другой поток и начинает асинхронную фоновую загрузку обновлений.
Загрузка осуществляется с помощью HTTP-DAV. DAV — это расширенная версия HTTP, которая обеспечивает такие функции, как перечисление каталогов и файлов. Полный процесс загрузки начинается с указания URL-адреса. URL-адрес, используемый для загрузки, зависит от метода, использованного для проверки обновлений. Например, если вы используете явные серверные файлы, URL-адрес, используемый для загрузки обновлений, указывается через атрибут ApplicationURL в явном файле сервера.
Загрузка обновлений, очевидно, требует некоторой надежности. Недопустимо оставлять клиентское приложение в нестабильном состоянии после загрузки и обновления. В процессе загрузки может возникнуть любое количество проблем: веб-сервер, которому принадлежит файл обновления, может быть неработоспособен, клиентский компьютер может выйти из строя или пользователь может просто закрыть приложение по какой-либо причине. Так как приложение загружается, то если его закрыть, то загрузка прекратится. Альтернативное конструктивное решение — использовать отдельные системные службы для загрузки и обновления приложений. С помощью системных служб загрузка обновлений продолжается даже тогда, когда само приложение не запущено. Фактически, в Windows XP есть встроенная служба загрузки под названием BITS, которая служит этой цели. BITS используется Windows XP для загрузки и обновления самой Windows. Дополнительные сведения о BITS см. на странице http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp . Эта служба не используется в компоненте обновления приложений .NET, поэтому ее можно использовать в Windows 9x, которая не поддерживает системные службы.
(3) Реализация обновлений.
Компонент обновления приложений .NET становится более надежным за счет разделения процессов загрузки и обновления на две отдельные фазы. По завершении каждого этапа он записывается в обновленный файл манифеста, расположенный в каталоге клиентского приложения. Если процесс загрузки или обновления прерван на каком-либо этапе, при следующем запуске приложения он возобновит исходную работу с последней завершенной точки останова. Каждый этап можно запустить повторно, поэтому, если в середине этапа произойдет сбой, перезапуск этапа будет успешным. Если произойдет ошибка, например потеря соединения с сервером во время загрузки, компонент обновления .NET попытается повторить попытку позже. Если сообщается о слишком большом количестве ошибок (например, веб-сервер никогда не подключается к сети), загрузка и обновление будут прерваны, и будет сообщено об ошибках.
Наш первый подход — просто запустить отдельный процесс для реализации обновления. Этот отдельный процесс сначала завершит процесс приложения, внедрит обновление (поскольку оно теперь разблокировано), перезапустит процесс приложения, а затем завершит работу по завершении. Таким образом, у этой конструкции есть три основные проблемы:
В некоторых случаях она не работает. Когда приложение обновляется, процесс обновления закрывает исходный процесс приложения, а также сам процесс обновления также закрывается, поэтому обновление не будет реализовано.
Мы хотим иметь возможность автоматически обновлять весь код, который необходимо обновить. Нам нужна возможность автоматически устанавливать исправления не только в приложении, но и в самом компоненте .NET Application Update. Используя этот режим, мы не можем обновить процесс, реализующий обновление.
. Невежливо заставлять пользователя закрывать приложение и ждать во время его использования.
Последний метод, используемый для реализации обновлений приложения, — использование шаблона параллельной сборки .NET Framework. В качестве альтернативы попытке обновления самого приложения создайте более новую версию приложения, чем существующая в данный момент.
Новые версии можно создавать путем объединения существующего каталога приложений с загруженными обновленными версиями. Когда новая версия будет завершена, пользователь автоматически будет использовать новую версию при следующем повторном открытии приложения. Копию исходного приложения затем можно удалить. Сложнее всего выяснить, какая версия должна быть загружена в данный момент. Мы представляем приложение под названием Appstart. Appstart — это точка входа в ваше приложение. В этом режиме каталог вашего приложения выглядит следующим образом: ..
--> Program Files
--> MyApp
--> Appstart.exe
--> Appstart.config
--> Папка V1
--. > MyApp.exe
--> Папка V1.1
--> MyApp.exe
Чтобы запустить приложение, вы обычно запускаете Appstart.exe. Если вы хотите иметь сочетание клавиш на рабочем столе, оно должно указывать на Appstart, а не непосредственно на приложение (обратите внимание, что вы можете переименовать AppStart.exe в любое другое имя, например YourApp.exe). Appstart.exe Это так. очень простая программа, которая читает файл Appstart.config и загружает указанное приложение. Действительный файл Appstart.config выглядит следующим образом:
<Config>
＜AppFolderName＞Папка V1＜/AppFolderName＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜AppLaunchMode＞домен приложения＜/AppLaunchMode＞
＜/Конфигурация＞
AppFolderName указывает подпапку, содержащую версию приложения, запускаемого в данный момент. AppExeName содержит имя exe-файла, который будет загружен в эту папку. После завершения обновления приложения последним шагом является изменение значения AppFolderName, чтобы оно указывало на новую версию приложения. Таким образом, при следующем запуске приложения пользователем будет запущена новая обновленная версия приложения. AppLaunchMode указывает, как загружается приложение. Есть два способа загрузки приложений. Первый способ — использовать AppDomains. AppDomains — это функция общеязыковой среды выполнения .NET Framework, а также независимая логическая единица и объект управления. Общеязыковая среда выполнения позволяет использовать несколько доменов приложений для каждого процесса. Таким образом, Appstart.exe может загрузить ваше приложение в отдельный AppDomain, но в том же процессе AppStart.exe. Несмотря на то, что запущены две разные программы exe (т. е. Appstart.exe и MyApp.exe), используется только один процесс. AppDomains прекрасно работает для большинства приложений, хотя есть некоторые тонкие различия между запуском в отдельном AppDomain и запуском в отдельном процессе. В этом случае для AppLaunchMode можно установить значение «process», что приведет к загрузке приложения в отдельном процессе.
Как только Appstart запускает приложение, оно переходит в спящий режим, ожидая завершения работы приложения. После закрытия приложения Appstart также закрывается.
3. Пример пошагового руководства
Ранее мы обсуждали, как работает обновление приложения .NET, теперь давайте применим это к примеру.
Шаг 1. Создайте приложение для обновления
1. С помощью VS.NET создайте новый проект приложения Windows с именем «SampleApp».
2. Придайте форме интересный цвет фона по вашему выбору. Мы будем использовать цвет фона, чтобы отличать его от более поздних обновленных версий.
3. Теперь давайте добавим в это приложение небольшую функцию. Сначала добавим кнопку в форму. Сжатый файл содержит сборку с простой формой Windows. Добавьте ссылку на сборку SamplesSampleAppSimpleForm в сжатый файл. Затем добавьте две строки кода в обработчик событий кнопки:
..
ПростаяФорма.Форма1 F = новая ПростаяФорма.Форма1();
Ф.Показать();
4. Преобразуйте свой флаг сборки из отладочного в RELEASE. Это позволит нам избежать проблем с блокировкой файла pdb позже, когда мы создадим новую версию приложения во время работы исходной копии. Создайте и протестируйте свое приложение.
Шаг 2. Добавьте компонент обновления приложения .NET.
1. На вкладке «Компоненты» панели инструментов VS.NET щелкните правой кнопкой мыши и выберите «Настроить панель инструментов». Выберите вкладку «Компоненты .NET Framework». Нажмите «Обзор» и выберите AppUpdater.dll, расположенный в проекте AppUpdater в сжатом файле, нажмите «ОК».
2. Значок AppUpdater теперь должен появиться внизу списка компонентов панели инструментов. Перетащите компонент AppUpdater в форму SampleApp. В нижней части формы появится экземпляр компонента обновления приложений .NET с именем appUpdater1.
Шаг 3. Настройка компонента обновления приложения .NET.
На этом этапе мы настроим компонент обновления приложения .NET. Обратите внимание, что в этом примере вам нужно изменить только первые четыре свойства, оставив для остальных значения по умолчанию.
Атрибут AppUpdater: это основа обновления приложения .NET. Для этой программы необходимо выполнить следующие настройки:
(1) AutoFileLoad: управляет характеристиками загрузки команды, которые будут описаны позже. Теперь установите для него значение true.
(2) ChangeDetectionMode: это перечисление определяет, как проверять наличие обновлений. В этом примере мы будем использовать явную проверку сервера, поэтому установите для этого значения значение «ServerManifestCheck».
(3) ShowDefaultUI: компонент обновления приложения .NET имеет ряд пользовательских интерфейсов для уведомления пользователей о некоторых событиях, таких как доступность нового обновления или ошибка, возникающая во время обновления. Этот пользовательский интерфейс можно отключить, установив для пользовательского интерфейса по умолчанию значение «Недопустимый» и заменив его пользовательским пользовательским интерфейсом для конкретного приложения, подключившись к соответствующим событиям (например,
OnUpdateComplete) и откройте пользовательский интерфейс. В этом примере мы будем использовать пользовательский интерфейс по умолчанию, поэтому установите для этого значения значение true.
(4) UpdateUrl: UpdateUrl определяет, где программа обновления будет искать обновления. В этом примере мы используем явный файл сервера для проверки наличия обновлений, поэтому для этого свойства должен быть установлен URL-адрес явного файла сервера.
В этом примере установите значение: http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml . Пожалуйста, замените «ваш веб-сервер» на имя вашего веб-сервера.
Свойство Downloader: компонент AppUpdater состоит из двух подкомпонентов. Первый называется Downloader и управляет свойствами загрузки и опроса компонента. Второй подкомпонент AppUpdater — Poller, который управляет проверкой обновлений.
(1) AutoStart: логическое значение, которое определяет, должен ли опросчик начинать опрос при запуске приложения или ему следует дождаться запуска запланированного запроса на обновление.
(2) DownloadOnDetection: логическое значение, определяет, начинает ли Poller загрузку обновлений немедленно при обнаружении нового обновления или следует начать явную загрузку, вызвав метод DownloadUdpate().
(3)InitialPollInterval: количество секунд ожидания перед выполнением первой проверки обновлений после запуска приложения.
(4)PollInterval: после первой проверки обновлений PollInterval контролирует количество секунд между каждой последующей проверкой обновлений. Примечание. По умолчанию проверка выполняется каждые 30 секунд. Очевидно, вы захотите, чтобы ваше приложение уменьшило количество проверок обновлений. .
После того, как все это будет сделано, ваша таблица свойств должна выглядеть следующим образом:
Каталог SamplesSampleAppSampleApp_Complete содержит правильно установленную версию приложения.
Установка:
(1)DownloadRetryAttempts: Если во время загрузки возникает ошибка (например, веб-сервер не работает), загрузчик повторит попытку позже. Это свойство контролирует количество повторных попыток загрузчика сетевого запроса, прежде чем считать его полной ошибкой обновления приложения.
(2)SecondsBeteweenDownloadRety: количество секунд ожидания перед повторной попыткой сетевого запроса.
(3)UpdateRetryAttempts: если во время обновления произойдет серьезная ошибка (например, загрузчик превысит количество повторных попыток), будет сгенерирована ошибка обновления приложения. По умолчанию попытки обновления будут прекращены. Но оно попытается восстановиться при следующем запуске приложения (например, обновление веб-сервера может быть недоступно в течение нескольких дней). Это свойство контролирует количество попыток обновления. Если это значение превышено, программа обновления отменяет обновление, сбрасывает свое состояние и возвращается к проверке обновлений.
(4)ValidateAssemblies: этот атрибут контролирует уровень, на котором загруженные сборки эффективно завершаются. Дополнительные сведения см. в разделе «Безопасность» этой статьи.
Шаг 4. Создайте и разверните версию приложения V1 на клиенте.
В проекте SampleApp откройте файл AssemblyInfo.cs. Измените значение AssemblyVersion с «1.0» на «1.0.0.0». Это приводит к тому, что при сборке сборки получается тег со значением «1.0.0.0».. вместо значения, которое VS.NET обычно указывает в качестве приращения.
1. Создайте приложение.
2. Скопируйте каталог SamplesSampleAppSampleApp_ClientSetup из сжатого файла на свой локальный компьютер. Обратите внимание, что этот каталог уже содержит AppStart.exe. AppStart.config настроен так, чтобы указывать на каталог 1.0.0.0 и запускать SampleApp.exe.
Скопируйте SampleApp (Appupdater.dll, SimpleForm.dll и SampleApp.exe) из каталога выпуска SampleApp
в клиентский каталог SampleApp_ClientSetup1.0.0.0. На данный момент полнофункциональная версия приложения «установлена» на клиенте и может быть запущена путем запуска AppStart.exe.
Шаг 5. Установите веб-сервер.
На этом этапе мы установим веб-сервер для обеспечения функции опроса обновлений. Компонент обновления приложений .NET использует HTTP-DAV для загрузки обновлений приложений, поэтому ему требуется веб-сервер, поддерживающий HTTP-DAV. IIS5.0 в Windows 2000 и более поздних операционных системах поддерживает HTTP-DAV.
1. Скопируйте каталог Samples/SampleApp_ServerSetup в каталог wwwroot на вашем веб-сервере.
2. Скопируйте версию SampleApp V1 в папку 1.0.0.0 веб-сервера.
3. Включите разрешение IIS «Обзор каталога» для каталога SampleApp_ServerSetup на веб-сервере.
Шаг шестой: автоматическое обновление приложений
Хорошо... Теперь пришло время увидеть результаты всей этой тяжелой работы путем автоматической установки новой версии.
1. Если версия SampleApp, которую вы развернули на клиенте, не работает, загрузите ее и дайте ей поработать. Не забудьте использовать AppStart.exe.
2. Вернитесь в VS.NET и внесите некоторые заметные изменения в форму SampleApp (например, измените цвет фона).
3. Измените информацию о версии AssemblyInfo.cs на 2.0.0.0.
4. Регенерируйте.
5. Вернитесь на веб-сервер и создайте каталог 2.0.0.0, эквивалентный каталогу 1.0.0.0. Скопируйте новую версию приложения из каталога создания выпуска во вновь созданный каталог 2.0.0.0 на веб-сервере.
6. Откройте UpdateVersion.xml и измените Доступную версию на 2.0.0.0. Измените URL-адрес приложения, чтобы он указывал на новый путь 2.0.0.0.
7. Сохраните изменения, внесенные в UpdateVersion.xml.
После сохранения нового файла UpdateVersion.xml в течение 30 секунд запуск копий SampleApp обнаружит новую доступную версию.
4. Установка по требованию, безопасность, масштабируемость и отладка
(1) Установка по требованию
Так называемая установка по требованию означает, что на клиентском компьютере явно устанавливается только основная исполняемая программа. Остальная часть приложения может быть автоматически загружена и установлена в зависимости от основных потребностей.
Запустите установку по требованию с помощью свойства AutoFileLoad компонента обновления приложения .NET. Вы должны тщательно продумать, где в вашем приложении находятся границы сборки и какие действия приведут к загрузке сборки. Поскольку загрузка сборки включает в себя ввод и вывод по сети, время, необходимое для загрузки, варьируется. Во время загрузки сборки приложение зависает в ожидании завершения загрузки сборки.
(2) Развертывание
Возможность автоматической безопасной установки обновлений приложений имеет множество преимуществ, но также сопряжена с некоторыми потенциальными опасностями. Упрощая установку обновлений, вы также можете упростить установку вредоносного кода, если не будете осторожны. Существует две опасности. Первая опасность заключается в том, что кто-то будет использовать собственный веб-сервер, чтобы обмануть веб-сервер, используемый для развертывания обновлений. Они могут использовать этот веб-сервер для установки вируса в путь к вашему приложению. Самый простой способ предотвратить спуфинг или другое несанкционированное вмешательство в сеть — использовать HTTPS. Чтобы использовать HTTPS с компонентом обновления приложений .NET, просто замените URL-адреса HTTP URL-адресами HTTPS. Конечно, HTTPS — не панацея. Есть две проблемы с использованием HTTPS. Первая — масштабируемость. Использование HTTPS требует, чтобы сервер шифровал все файлы, загруженные с веб-сервера. Если файлы обновлений приложения большие, затраты на шифрование файлов обновлений могут перегрузить сервер. Другая проблема с использованием HTTPS заключается в том, что он не способствует второй угрозе безопасности. Вторая опасность заключается в том, что хакеры могут атаковать ваш сервер как изнутри, так и снаружи. Если атака окажется успешной, это может означать, что сотни или тысячи клиентов также будут затронуты автоматическими обновлениями, что будет иметь катастрофические последствия.
Чтобы решить эту проблему, компонент обновления приложений .NET использует функцию строгого имени для сборок .NET для проверки загруженных сборок. Если компонент обновления приложений .NET обнаружит, что сборка не подписана вашим ключом во время загрузки, загрузка будет отменена. Это означает, что только тот, у кого есть закрытый ключ вашего приложения, может создавать обновления, которые могут быть развернуты автоматически.
Чтобы убедиться в правильности сборки, компонент .NET Application Update проверяет соответствие открытого ключа установленного в данный момент исполняемого файла приложения и открытого ключа загруженного обновления. Если две сборки подписаны одним и тем же секретным закрытым ключом, то встроенный открытый ключ будет одинаковым. Поскольку сборка, загружаемая средой CLR, проверяет свой открытый ключ, CLR вычисляет обычную проверку хэш-функции, чтобы убедиться, что сборка на самом деле является подлинной сборкой, а не подделанной сборкой. Чтобы включить проверку во время загрузки, добавьте строгие имена ко всем сборкам приложения и установите для свойства ValidateAssemblies компонента .NET Application Update значение true.
Проверка сборки во время загрузки очень помогает, но на практике компоненты приложений часто подписаны разными закрытыми ключами. Например, ваше приложение может иметь два файла: исполняемую сборку, подписанную вашим закрытым ключом, и другую сборку dll, содержащую сторонний элемент управления диаграммой, который вы приобрели и использовали в своем приложении. Сторонние сборки могут быть подписаны с использованием стороннего закрытого ключа вместо вашего собственного. Ситуация еще больше усложняется тем, что настройки действительных закрытых ключей, используемых для подписи сборок в вашем приложении, могут меняться с номера версии на номер версии. Как автоматически обновлять эти типы приложений? Чтобы решить эту проблему, вы можете создать в своем приложении сборку, содержащую список допустимых открытых ключей. Подпишите сборку с помощью главного закрытого ключа приложения (ключ, используемый для подписи exe-файла приложения) и поместите сборку в каталог на веб-сервере с файлами обновления приложения. Прежде чем начнется процесс загрузки обновления, компонент обновления приложений .NET проверит наличие сборки с именем «AppUpdaterKeys.dll» в каталоге обновления приложения на веб-сервере. Если присутствует, сборка загружается. Сборка проверяется по открытому ключу основного приложения. Если подпись действительна, извлекается список ключей. С этого момента любой ключ в этом списке будет считаться действительной подписью обновленного файла.
Рекомендуемый подход к обеспечению безопасности — использовать URL-адреса HTTPS для проверки обновлений. Это обеспечивает первый уровень защиты от спуфинга. Для загрузки обновлений лучше не использовать HTTPS RL, чтобы не перегружать веб-сервер. Вместо этого добавьте строгие имена к сборкам вашего приложения и используйте функцию проверки сборок.
(3) Масштабируемость
В примере, упомянутом ранее в этой статье, мы просто перетащили компонент в приложение и установили некоторые свойства для автоматического развертывания.
Хотя это хорошо работает во многих приложениях, некоторые приложения требуют высокого уровня контроля, который можно получить только путем написания кода. Мы можем написать собственный код, который заменит стандартный процесс компонента обновления приложения .NET, используя переопределенные методы CheckForUpdate() и ApplyUpdate() для настройки поведения проверки и обновления.
(4) Отладка
В этом разделе будут указаны некоторые предпочтительные варианты отладки, а также описаны наиболее распространенные проблемы, с которыми сталкиваются пользователи этого компонента.
Средство обновления приложений .NET создает скрытый файл журнала с именем AppUpdate.log в том же каталоге, что и AppStart.exe.
Вся информация об успешных и неудачных обновлениях записывается в этот журнал. Файл журнала особенно полезен, когда конкретный клиент не может успешно обновиться.
Вы можете использовать журналы, чтобы определить, когда и как произошел сбой при обновлении. Кроме того, компонент .NET Application Update использует класс Debug .NET Framework для вывода большого количества полезной информации. Если вы запустите приложение в отладчике, вы увидите эту информацию в окне вывода. Вы можете следить за журналами средства обновления приложений .NET, чтобы выделить и найти проблемные области.
Если по какой-либо причине вам не удается запустить программу обновления приложений .NET, прежде чем приступать к отладке, убедитесь в следующем. Проблема, с которой вы столкнулись, скорее всего, одна из следующих: ..
Вы перешли к IIS. каталог открыт? В противном случае программа обновления не будет загружать и устанавливать какие-либо файлы.
Вы все правильно развернули и правильно указали URL?
. Если ваше приложение установлено в каталоге программных файлов, вы уверены, что являетесь суперадминистратором или суперпользователем компьютера? В противном случае у вас не будет доступа на запись для обновления приложения.
Вы создаете объект AppUpdater в основном потоке пользовательского интерфейса приложения? В противном случае программа обновления не сможет отобразить пользовательский интерфейс и завершится сбоем при отправке события обратно в пользовательский интерфейс.
. Обновление выполнено успешно, но приложение не перезапускается автоматически с новым обновлением? Компонент обновления приложения .NET пытается выйти из приложения, вызывая метод Application.Exit. Однако этот метод не гарантирует закрытие приложения. Если вы создадите и оставите отдельный поток работающим, этот метод не сможет завершить процесс. Чтобы гарантировать завершение всех потоков, можно вызвать событие Application.OnExit или подключиться к событию OnUpdateComplete средства обновления приложений .NET и самостоятельно выполнить завершение работы.
5. Резюме
Удобное развертывание клиентских приложений — важная цель первой версии .NET Framework. Использование .NET Framework — отличный метод создания клиентских приложений, решающих проблемы развертывания. Простота развертывания остается важной целью будущих новых версий .NET Framework. В качестве решения описанный здесь компонент обновления приложений .NET представляет некоторые из наших идей, которые мы сможем использовать непосредственно в будущих версиях .NET Framework. Однако в период до того, как это время наступит, компонент обновления приложений .NET можно рассматривать как важный способ начать создание приложений автоматического обновления.
От: csdn, я видел это на Tianji, я еще не изучал его внимательно, я. оставлю это на потом.