Создание приложений ClickOnce для развертывания другими
Обновлен: Ноябрь 2007
Не все разработчики, создающие развертывания ClickOnce, планируют развертывать приложения сами. Многие из них просто упаковывают свое приложение, используя технологию ClickOnce, а затем передают файлы клиенту, например большой корпорации. Клиент становится ответственным за размещение приложения в своей сети. В этой статье рассматриваются некоторые проблемы, присущие таким развертываниям в версиях .NET Framework, предшествующих версии 3.5. Затем описывается новое решение, предоставляемое с помощью новой возможности "использовать манифест для доверия" в .NET Framework 3.5. В заключение приводятся рекомендуемые стратегии создания развертываний ClickOnce для клиентов, которые по-прежнему пользуются более старыми версиями .NET Framework.
Вопросы, связанные с созданием развертываний для клиентов
При планировании поставки развертывания клиенту возникает несколько вопросов. Первый вопрос касается подписания кода. Чтобы выполнить развертывание в сети, манифест развертывания и манифест приложения для развертывания ClickOnce должны быть подписаны цифровым сертификатом. В связи с этим возникает вопрос, должен ли использоваться сертификат разработчика или сертификат клиента при подписании манифестов.
Вопрос относительно того, какой сертификат должен использоваться, является важным, поскольку удостоверение приложения ClickOnce основывается на цифровой подписи манифеста развертывания. Когда разработчик подписывает манифест развертывания, это может привести к конфликтам, если клиентом является крупная компания, и настраиваемую версию приложения разворачивают в нескольких подразделениях компании.
Например, предположим, что в компании "Adventure Works" имеется финансовый отдел и отдел кадров. Оба отдела лицензируют приложение ClickOnce от корпорации Майкрософт, которое создает отчеты из данных, хранящихся в базе данных SQL. Корпорация Майкрософт поставляет в каждый отдел версию приложения, которая настроена под их данные. Если приложения подписаны одним и тем же сертификатом Authenticode, пользователь, пытающийся использовать оба приложения, столкнется с ошибкой, так как ClickOnce будет считать второе приложение идентичным первому. В этом случае клиент мог бы столкнуться с непредсказуемыми и нежелательными побочными эффектами, которые включают потерю каких-нибудь данных, хранящихся приложением локально.
Дополнительную проблему, связанную с подписанием кода, представляет элемент deploymentProvider в манифесте развертывания, который сообщает ClickOnce, где искать обновления приложения. Этот элемент должен быть добавлен в манифест развертывания до его подписания. Если данный элемент добавляется после подписания, необходимо заново подписать манифест развертывания.
Требование подписания клиентом манифеста развертывания
Одно решение этой проблемы неуникальных развертываний состоит в требовании, чтобы разработчик подписывал манифест приложения, а клиент подписывал манифест развертывания. Хотя этот подход работает, с ним возникают другие вопросы. Так как сертификат Authenticode должен оставаться защищенным активом, клиент не может просто дать сертификат разработчику для подписания развертывания. Хотя клиент может подписать манифест развертывания сам, используя средства, свободно доступные с набором инструментальных средств разработки (SDK) .NET Framework, это может потребовать больше технических знаний, чем те, которые клиент желает или способен предоставить. В подобных случаях разработчик обычно создает приложение, веб-узел или другой механизм, через который клиент может передать свою версию приложения для подписания.
Влияние подписания клиентом на безопасность приложения ClickOnce
Даже если разработчик и клиент соглашаются, что клиент должен подписывать манифест приложения, это влечет за собой другие вопросы, которые касаются удостоверения приложения, особенно поскольку оно применяется к развертыванию доверенного приложения. (Дополнительные сведения об этой возможности см. в разделе Общие сведения о развертывании доверенных приложений.) Допустим, что в компании "Adventure Works" хотят настроить свои клиентские компьютеры таким образом, чтобы любое приложение, предоставляемое корпорацией Майкрософт, выполнялось с полным доверием. Если в компании "Adventure Works" подписывают манифест развертывания, тогда ClickOnce использует подпись безопасности "Adventure Works" для определения уровня доверия приложения.
Создание клиентских развертываний посредством использования манифеста приложения для доверия
Технология ClickOnce в .NET Framework 3.5 содержит новую возможность, которая предоставляет разработчикам и клиентам новое решение для сценария подписания манифестов. Манифест приложения ClickOnce поддерживает новый элемент, именуемый как <useManifestForTrust>, который позволяет разработчику показать, что именно цифровая подпись манифеста приложения должна использоваться для принятия решений о доверии. Разработчик используется средства упаковки ClickOnce — например Mage.exe, MageUI.exe и Visual Studio — для включения этого элемента в манифест приложения, а также для внедрения в манифест имени издатели и имени приложения.
При использовании <useManifestForTrust> манифест развертывания не должен подписываться сертификатом Authenticode, выпускаемым центром сертификации. Вместо этого он может подписываться так называемым самозаверяющим сертификатом. Самозаверяющий сертификат создается клиентом или разработчиком с помощью стандартных средств набора SDK .NET Framework и затем применяется к манифесту развертывания путем использования стандартных средств развертывания ClickOnce. Дополнительные сведения см. в разделе Средство создания сертификатов (Makecert.exe).
Использование самозаверяющего сертификата для манифеста развертывания представляет несколько преимуществ. Путем исключения необходимости для клиента получать или создавать свой собственный сертификат Authenticode <useManifestForTrust> упрощает развертывание для клиента, при этом разрешая разработчику сохранять свой фирменный стиль в приложении. Результатом является набор подписанных развертываний, которые более надежны и имеют уникальные удостоверения приложений. Это устраняет потенциальный конфликт, который может возникнуть при развертывании одного приложения для нескольких клиентов.
Сведения о пошаговой процедуре создания развертывания ClickOnce с включенным параметром <useManifestForTrust> см. в статье Пошаговое руководство. Развертывание вручную приложения ClickOnce, которое не нуждается в повторном подписывании и которое сохраняет фирменную символику.
Работа манифеста приложения для доверия в среде выполнения
Для лучшего понимания работы манифеста приложения для доверия в среде выполнения, рассмотрите следующий пример. Корпорацией Майкрософт создано приложение ClickOnce, рассчитанное на .NET Framework 3.5. Манифест приложения использует элемент <useManifestForTrust> и подписывается корпорацией Майкрософт. Компания "Adventure Works" подписывает манифест развертывания, используя самозаверяющий сертификат. Клиенты компании "Adventure Works" настроены на доверие любому приложению, подписанному корпорацией Майкрософт.
Когда пользователь щелкает ссылку на манифест развертывания, ClickOnce устанавливает приложение на компьютер пользователя. Сертификат и сведения развертывания однозначно определяют приложение для службы ClickOnce на клиентском компьютере. Если пользователь пытается установить то же приложение еще раз из другого места, ClickOnce может использовать это удостоверение, чтобы определить наличие приложения на клиенте.
Далее ClickOnce проверяет сертификат Authenticode, используемый для подписания манифеста приложения, который определяет уровень доверия, предоставляемый службой ClickOnce. Так как в компании "Adventure Works" клиенты сконфигурированы на доверие любому приложению, подписанному корпорацией Майкрософт, этому приложению ClickOnce предоставляется полное доверие. Дополнительные сведения см. в разделе Общие сведения о развертывании доверенных приложений.
Создание клиентских развертываний для более ранних версий
Что если разработчик развертывает приложения ClickOnce на клиентские компьютеры, использующие более старые версии .NET Framework? В следующих разделах обобщаются некоторые рекомендованные решения вместе с преимуществами и недостатками каждого из них.
Подписание развертываний от имени клиента
Одна возможная стратегия развертывания рассчитана на разработчика для создания механизма подписания развертываний от имени их клиентов, с помощью собственного закрытого ключа клиента. Это предотвращает управление со стороны разработчика закрытыми ключами или несколькими пакетами развертывания. Разработчик просто предоставляет одно и то же развертывание каждому клиенту. Настройкой под свою среду с помощью службы подписания занимается клиент.
Одним недостатком этого метода являются время и затраты на его реализацию. Хотя такая служба может быть создана с помощью средств, предоставляемых в наборе SDK для .NET Framework, это связано с дополнительным временем разработки, входящим в цикл жизни программного продукта.
Как упоминалось ранее в этой статье, другой недостаток состоит в том, что версии приложения всех клиентов будут иметь одинаковое удостоверение приложения, что может приводить к конфликтам. Если это является предметом беспокойства, разработчик может изменить поле "Имя", которое используется при создании манифеста развертывания для присвоения каждому приложению уникального имени. Это позволяет отдельно идентифицировать каждую версию приложения и исключить любые потенциальные конфликты идентичности. Данное поле соответствует аргументу -Name для Mage.exe и полю Имя на вкладке Имя в MageUI.exe.
Например, предположим, что разработчик создал приложение с именем "Приложение1". Вместо создания одного развертывания с полем "Имя", установленным в значение "Приложение1", разработчик может создать несколько развертываний, варьируя это имя в зависимости от клиента, например "Приложение1-КлиентA", "Приложение1-КлиентБ" и так далее.
Развертывание с помощью пакета установки
Вторая возможная стратегия развертывания состоит в создании проекта установки Microsoft для выполнения начального развертывания приложения ClickOnce. Данный проект может быть предоставлен в одном из нескольких разных форматов: как MSI-развертывание, как исполняемый файл установки (.EXE) или как CAB-файл вместе с пакетным сценарием.
Используя этот метод, разработчик предоставляет клиенту развертывание, которое содержит файлы приложения, манифест приложения и манифест развертывания, служащий в качестве шаблона. Клиент выполнит эту программу установки, которая запрашивает URL-адрес развертывания (местоположение сервера или общего файлового ресурса, из которого пользователи установят приложение ClickOnce) и цифровой сертификат. Приложение установки может также выбрать вывод запроса о дополнительных параметрах настройки ClickOnce, например интервала проверки наличия обновлений. После того как эти сведения собраны, программа установки создаст реальный манифест развертывания, подпишет его и опубликует приложение ClickOnce в указанное местоположение на сервере.
В данной ситуации существует три способа подписания клиентом манифеста развертывания:
Клиент может использовать действительный сертификат, выпущенный центром сертификации.
В качестве варианта данного подхода клиент может выбрать подписание своего манифеста развертывания самозаверяющим сертификатом. Недостаток этого варианта состоит в том, что когда для пользователя выводится запрос о необходимости установки приложения, приложением отображается фраза "Unknown Publisher" (Неизвестный издатель). Однако преимущество такого подхода заключается в предотвращении необходимости для небольших клиентов тратить время и деньги на сертификат, выпускаемый центром сертификации.
Наконец, разработчик может включить в пакет установки свой собственный самоподписывающий сертификат. Это приводит к появлению потенциальных проблем с удостоверением приложения, рассмотренных ранее в этой статье.
Недостатком метода проекта развертывания установки являются время и затраты, необходимые для построения настраиваемого приложения развертывания.
Создание манифеста развертывания клиентом
Третья возможная стратегия развертывания состоит в передаче клиенту только файлов приложения и манифеста приложения. В этом сценарии клиент отвечает за использование набора инструментальных средств разработки (SDK) .NET Framework для создания и подписания манифеста развертывания.
Недостаток этого метода — требование, чтобы клиент установил средства SDK для .NET Framework и необходимость наличия разработчика или системного администратора, умеющего пользоваться этими средствами. Некоторые клиенты могут запросить решение, которое требует небольших или никаких технических усилий с их стороны.
См. также
Задачи
Пошаговое руководство. Развертывание приложения ClickOnce вручную