Манифест надстроек Office

Каждая надстройка Office имеет манифест. Существует два типа манифестов:

  • XML-манифест: Это единственный тип манифеста, который в настоящее время поддерживается для рабочих надстроек. Как указывает имя, это формат XML. Этот тип манифеста нельзя использовать для приложения, которое объединяет надстройку с каким-либо другим типом приложения Teams. то есть, какое-то другое расширение платформы Microsoft 365.
  • унифицированный манифест для Microsoft 365: Это манифест в формате JSON, который в течение многих лет использовался в качестве манифеста для приложений Teams. В настоящее время он поддерживается только для надстроек в качестве предварительной версии и только в Outlook для Windows. Его не следует использовать с рабочей надстройкой. При выпуске в общедоступной версии надстройки, использующие этот манифест, можно сочетать с другими типами приложений Teams в одном приложении, которое можно установить как единое целое.

Оставшаяся часть этой статьи применима к обоим типам манифестов.

Совет

В файле манифеста надстройки Office описывается, как должна активироваться надстройка, когда пользователь устанавливает ее и использует ее с документами и приложениями Office.

Файл манифеста позволяет надстройке Office выполнять следующие действия:

  • предоставлять идентификатор, версию, описание, отображаемое имя и языковой стандарт по умолчанию.

  • указывать изображения, используемые для фирменного оформления надстройки, и значки, используемые для команд надстройки на ленте приложения Office;

  • указывать, как надстройка интегрируется с Office, включая создаваемые ею элементы пользовательского интерфейса, например кнопки на ленте;

  • определять запрошенные размеры по умолчанию для контентных надстроек, а также запрошенную высоту для надстроек Outlook;

  • объявлять разрешения, в которых нуждается надстройка Office, например чтение или запись документа;

Примечание.

Если вы планируете опубликовать надстройку в AppSource и Office, она должна соответствовать Политикам сертификации коммерческого рынка.  Например, она должна работать на всех платформах, поддерживающих определенные вами методы. Дополнительные сведения см. в разделе 1120.3 и на странице с информацией о доступности для платформ и приложений Office.

Требования к размещению

Все URI образов, например используемые для команд надстроек, должны поддерживать кэширование в рабочей среде. Сервер, на котором размещено изображение, не должен возвращать заголовок, указывающий Cache-Controlno-cache, no-storeили аналогичные параметры в HTTP-ответе. Однако при разработке надстройки и внесении изменений в файлы изображений кэширование может препятствовать просмотру изменений, поэтому при разработке рекомендуется использовать Cache-Control заголовки.

Все URL-адреса для файлов кода или содержимого в надстройке должны быть защищены SSL (HTTPS). Использовать конечную точку HTTPS для надстройки не обязательно, но настоятельно рекомендуется. Надстройки без SSL-защиты (HTTPS) выдают предупреждения о небезопасном контенте и ошибки во время использования. Если вы планируете запустить надстройку в Office в Интернете или опубликовать ее в AppSource, она должна быть защищена SSL. Если надстройка получает данные из внешнего источника, она должна использовать SSL-соединение для защиты данных при передаче. Самозаверяющие сертификаты можно использовать для разработки и тестирования, если они добавлены в список доверенных сертификатов на локальном компьютере.

Рекомендации по отправке решений в AppSource

Убедитесь, что идентификатор надстройки представляет собой допустимый и уникальный GUID. В Интернете доступно множество генераторов, с помощью которых можно создать уникальный GUID.

Надстройки, отправленные в AppSource, также должны содержать URL-адрес поддержки в манифесте. Дополнительные сведения см. в статье Политики проверки для приложений и надстроек, отправляемых в AppSource.

Укажите домены, которые необходимо открыть в окне надстройки

В Office в Интернете область задач может открывать любой URL-адрес. Однако на классических платформах, если надстройка пытается перейти по URL-адресу в домене, отличном от домена, в котором размещена начальная страница (как указано в файле манифеста), этот URL-адрес открывается в новом окне браузера за пределами области надстройки приложения Office.

Чтобы переопределить это поведение (классический Office), укажите каждый домен, который нужно открыть, в окне надстройки манифеста. URL-адреса в доменах из списка будут открываться в области задач как в классическом Office, так и в Office в Интернете. URL-адреса в доменах не из списка будут открываться в новом окне браузера (не в области надстроек) в классическом Office.

Примечание.

Из этого правила есть два исключения.

  • Это относится только к корневой области надстройки. Если на странице надстройки есть iframe, он может быть направлен на любой URL-адрес, независимо от того, указан ли он в манифесте, даже в классическом Office.
  • При открытии диалогового окна с помощью API displayDialogAsync URL-адрес, передаваемый методу, должен находиться в том же домене, что и надстройка, но затем диалог может быть направлен на любой URL-адрес независимо от того, указан ли он в манифесте, даже в классическом Office.

Указание доменов, из которых выполняются вызовы API Office.js

Надстройка может выполнять Office.js вызовы API из домена ad-in, на который ссылается файл манифеста. Если у вас есть другие iframes в надстройке, которым требуется доступ Office.js API, добавьте домен исходного URL-адреса в файл манифеста. Если iframe с источником, не указанным в манифесте, пытается выполнить вызов API Office.js, надстройка получит ошибку "Отклонено в разрешении".

См. также