Share via

Создание приложений ClickOnce для развертывания другими пользователями

  • Статья

Не все разработчики, которые создают развертывания 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 Work для определения уровня доверия приложения.

Создание развертываний клиентов с помощью манифеста приложения для доверия

ClickOnce в платформа .NET Framework 3.5 содержит новую функцию, которая предоставляет разработчикам и клиентам новое решение для сценария подписи манифестов. Манифест приложения ClickOnce поддерживает новый элемент с именем <useManifestForTrust> , который позволяет разработчику обозначить, что цифровая подпись манифеста приложения — это то, что следует использовать для принятия решений о доверии. Разработчик использует такие средства упаковки ClickOnce, как Mage.exe, MageUI.exe и Visual Studio, чтобы включить этот элемент в манифест приложения, а также внедрить имя издателя и имя приложения в манифест.

При использовании <useManifestForTrust>манифест развертывания не должен быть подписан с помощью сертификата Authenticode, выданного центром сертификации. Вместо этого его можно подписать с помощью самозаверяющего сертификата. Самозаверяющий сертификат создается клиентом или разработчиком с помощью стандартных средств платформа .NET Framework SDK, а затем применяется к манифесту развертывания с помощью стандартных средств развертывания ClickOnce. Дополнительные сведения см. в разделе MakeCert.

Использование самозаверяющего сертификата для манифеста развертывания дает несколько преимуществ. Устраняя необходимость получения или создания собственного сертификата 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.

Например, предположим, что разработчик создал приложение с именем Application1. Вместо создания одного развертывания с полем "Имя", заданного в Application1, разработчик может создать несколько развертываний с определенным клиентом вариантом этого имени, например Application1-CustomerA, Application1-CustomerB и т. д.

Развертывание с помощью пакета установки

Вторая возможная стратегия развертывания — создать проект установки Майкрософт для выполнения первоначального развертывания приложения ClickOnce. Это может быть предоставлено в одном из нескольких различных форматов: как развертывание MSI, как исполняемый файл установки (.EXE) или в виде cab-файла (CAB-файла) вместе с пакетным скриптом.

С помощью этого метода разработчик предоставит клиенту развертывание, включающее файлы приложения, манифест приложения и манифест развертывания, который служит шаблоном. Клиент запустит программу установки, которая предложит им url-адрес развертывания (сервер или расположение общей папки, из которого пользователи установят приложение ClickOnce), а также цифровой сертификат. Приложение установки также может запрашивать дополнительные параметры конфигурации ClickOnce, например интервал обновления проверка. После сбора этих сведений программа установки создаст манифест реального развертывания, подписывает его и публикует приложение ClickOnce в указанном расположении сервера.

В этой ситуации клиент может подписать манифест развертывания тремя способами:

  1. Клиент может использовать действительный сертификат, выданный центром сертификации (ЦС).

  2. В качестве варианта этого подхода клиент может подписать манифест развертывания с помощью самозаверяющего сертификата. Недостатком этого является то, что приложение приведет к отображению слов "Неизвестный издатель", когда пользователю будет предложено установить его. Тем не менее, преимущество заключается в том, что это препятствует небольшим клиентам тратить время и деньги, необходимые для сертификата, выданного центром сертификации.

  3. Наконец, разработчик может включить собственный самозаверяющий сертификат в пакет установки. Это приводит к потенциальным проблемам с удостоверением приложения, рассмотренным ранее в этом разделе.

    Недостатком метода проекта развертывания установки является время и расходы, необходимые для создания пользовательского приложения развертывания.

Создание манифеста развертывания клиентом

Третья возможная стратегия развертывания заключается в том, чтобы передать только файлы приложения и манифест приложения клиенту. В этом сценарии клиент отвечает за использование пакета SDK платформа .NET Framework для создания и подписывания манифеста развертывания.

Недостатком этого метода является то, что клиенту требуется установить средства пакета SDK платформа .NET Framework, а также иметь разработчика или системного администратора, который имеет опыт использования. Некоторым клиентам может потребоваться решение, требующее мало или нет технических усилий на их стороне.

Связанный контент