Как изменить файл манифеста
Обновлено: 05.07.2024
У меня два исполняемых файла, первый - второй. Второй - с различными типами манифестаций: asInvoker , requireAdministrator и т.д.
Можно ли изменить манифест исполняемого файла? Я ищу простое решение на C
Я бы хотел не хранить несколько экземпляров исполняемого файла с различными типами манифестаций, а не поддерживать инструмент сторонних разработчиков, который мог бы его изменить. Кстати, это возможно, и этот инструмент существует: MT (инструмент манифеста) из пакета visual studio, link.
Да, вы можете изменить файл манифеста с помощью mt.exe из Win32 SDK. Но это только то, что вы должны делать во время разработки или тестирования. Вы не можете развернуть этот инструмент на машине клиента, поэтому вы не можете использовать его для динамического изменения манифеста взад и вперед.
Но это нормально, потому что вам никогда не нужно менять файл манифеста взад и вперед во время выполнения. Файл исполняемого файла манифеста должен указывать минимальные требуемые привилегии для этого EXE. Таким образом, если пользователь может запустить EXE без административных привилегий (т.е. Без повышения) - даже если это означает, что приложение работает с ограниченной функциональностью - манифест приложения должен указывать "asInvoker". Пользователь может всегда выбирать для запуска приложения с правами администратора, если им нужны эти дополнительные функции.
И, конечно же, вы можете запускать EXE программно с повышением. Вы делаете это с помощью ShellExecuteEx , указывая глагол "runas" для параметра lpVerb . Это будет иметь такой же эффект, как установка уровня разрешений в манифесте приложения на "requireAdministrator".
С вашего вопроса не совсем ясно, как настроено ваше приложение. Обычно первый EXE имеет "asInvoker" в своем манифесте, чтобы любой пользователь мог его запустить. Для этого не нужны административные привилегии. Однако, если есть что-то, что может потребоваться для этого, требуются административные привилегии, он отображает некоторый бит пользовательского интерфейса с значком экрана UAC, и при нажатии на него запускается второй EXE (с установленным в манифесте "requireAdministrator"), который выполняет все задача требует повышения. Это второе приложение не нужно распространять в форме "asInvoker", потому что для него всегда требуется повышение. Вы заметите, что именно так настроены все приложения Microsoft, включая биты, поставляемые с операционной системой.
Вместо программы Mage.exe можно также использовать графическое приложение MageUI.exe. Для получения дополнительной информации см. MageUI.exe (средство создания и редактирования манифестов, графический клиент).
Эта программа автоматически устанавливается вместе с Visual Studio. Для запуска этого средства используйте Командную строку разработчика или PowerShell для разработчиков в Visual Studio.
В Visual Studio входят две версии Mage.exe и MageUI.exe. Чтобы просмотреть сведения о версии, запустите программу MageUI.exe, откройте меню Справка и выберите пункт О программе. В данной документации представлено описание программ Mage.exe и MageUI.exe версии 4.0.x.x.
Синтаксис
Параметры
В следующей таблице показаны команды, поддерживаемые программой Mage.exe. Дополнительные сведения о параметрах этих команд см. в разделах Параметры команд "New" и "Update" и Параметры команды "Sign".
- Deployment : Создает новый манифест развертывания.
- Application : Создает новый манифест приложения.
Если для этой команды не заданы никакие дополнительные параметры, она создаст файл соответствующего типа, с соответствующими тегами по умолчанию и значениями атрибутов.
Чтобы задать имя и путь для нового файла, используется параметр -ToFile (см. в следующей таблице).
Если файл уже подписан с помощью сертификата, при использовании параметра -Update блок подписи ключа будет удален. Это обусловлено тем, что подпись ключа содержит хэш файла и изменение файла делает хэш недействительным.
Параметры команд "New" и "Update"
В следующей таблице приведены параметры команд -New и -Update :
Mage.exe никогда не помечает файл как файл "данных". Это необходимо сделать вручную. Дополнительные сведения см. в разделе Практическое руководство. включить файл данных в приложение ClickOnce.
Mage.exe также создает хэш для каждого файла в зависимости от его размера. Технология ClickOnce использует эти хэши, чтобы гарантировать отсутствие злонамеренного изменения файлов развертывания с момента создания манифеста. При изменении любого из файлов развертывания можно запустить Mage.exe с командой -Update и параметром -FromDirectory, и она обновит хэши и версии сборки для всех указанных файлов.
-FromDirectory включает все файлы во всех подкаталогах, найденных в каталоге directoryPath .
Если задан параметр -MinVersion и пользователь использует версию, более раннюю по сравнению с -MinVersion , этот параметр вызывает принудительную установку приложения, независимо от значения, переданного в -Install.
Для манифестов приложений вставляет атрибут hostInBrowser под элементом entryPoint манифеста приложения.
Параметры команды "Sign"
В следующей таблице указаны параметры команды -Sign , применяемой ко всем типам файлов.
Примечания
Все аргументы программы Mage.exe не зависят от регистра символов. Перед командами и параметрами должен быть поставлен дефис (-) или косая черта (/).
Все аргументы, используемые с командой -Sign , всегда можно использовать вместе с командой -New или -Update . Следующие команды являются эквивалентными.
Подписание — это последняя задача, которую должен выполнить разработчик, поскольку для проверки правильности подписи документа подписанный документ использует хэш файла. При внесении в файл каких-либо изменений разработчик должен снова подписать этот файл. Если подписывается документ, который уже был подписан, Mage.exe заменяет старую подпись новой.
При использовании параметра -AppManifest для заполнения манифеста развертывания программа Mage.exe предполагает, что манифест приложения будет находиться в том же каталоге, что и манифест развертывания, в подкаталоге, название которого соответствует текущей версии развертывания, и соответствующим образом настраивает манифест развертывания. Если манифест приложения будет находиться в другом месте, для указания альтернативного расположения можно использовать параметр -AppCodeBase .
Перед развертыванием приложения манифест развертывания и манифест приложения должны быть подписаны. Руководство по подписанию документов см. в разделе Trusted Application Deployment Overview.
Параметр -TrustLevel для манифестов приложений описывает набор разрешений, необходимых приложению для выполнения на клиентском компьютере. По умолчанию уровень доверия, назначаемый приложениями, зависит от зоны , в которой находится URL-адрес. Приложения, развертываемые в корпоративной сети, обычно помещаются в зоне интрасети, а приложения, развертываемые через Интернет, размещаются в зоне Интернета. Обе зоны безопасности налагают на приложение ограничения доступа к локальным ресурсам, при этом зона интрасети предоставляет чуть больше прав, чем зона Интернета. В зоне полного доверия (FullTrust) приложениям предоставляется полный доступ к локальным ресурсам компьютера. Если для помещения приложения в эту зону используется параметр -TrustLevel, менеджер доверия среды CLR предложит пользователю решить, следует ли предоставить повышенный уровень доверия. Если приложение развертывается в корпоративной сети, можно использовать развертывание доверенных приложений, чтобы повысить уровень доверия приложения без участия пользователя.
Манифесты приложений также поддерживают настраиваемые разделы доверия. Это помогает приложению соблюдать принцип безопасности (запрос минимально необходимых разрешений), позволяя настроить манифест на запрос только конкретных разрешений, которые требуются приложению для работы. Mage.exe не поддерживает прямое добавление настраиваемого раздела доверия. Такой раздел можно добавить с помощью текстового редактора, средства синтаксического анализа XML или графического средства MageUI.exe. Дополнительные сведения об использовании MageUI.exe для добавления настраиваемых разделов доверия см. в разделе MageUI.exe (инструмент создания и изменения манифестов, графический клиент).
В следующих таблицах показаны эти возможности и ограничения.
Примеры
В следующем примере показано открытие пользовательского интерфейса для программы Mage (MageUI.exe).
В следующих примерах показано создание манифеста развертывания и манифеста приложения по умолчанию. Эти файлы создаются в текущем рабочем каталоге и называются "deploy.application" и "application.exe.manifest" соответственно.
В следующем примере показано создание манифеста приложения, заполненного всеми сборками и файлами ресурсов из текущего каталога.
В следующем примере показано продолжение предыдущего примера с указанием имени развертывания и целевого микропроцессора. В нем также показано задание URL-адреса, который приложение ClickOnce должно использовать для проверки обновлений.
В следующем примере показано создание пары манифестов для развертывания приложения WPF, размещаемого в Internet Explorer.
В следующем примере показано создание манифеста приложения, заполненного всеми сборками и файлами ресурсов из текущего каталога и необходимыми подписями.
В следующем примере в манифест развертывания добавляются сведения из манифеста приложения и задается база кода для местонахождения манифеста приложения.
В следующем примере изменяется манифест развертывания для принудительного обновления установленной у пользователя версии.
В следующем примере манифест развертывания получает указание извлекать манифест приложения из другого каталога.
В следующем примере существующий манифест развертывания подписывается с помощью цифрового сертификата в текущем рабочем каталоге.
В следующем примере существующий манифест развертывания подписывается с помощью цифрового сертификата и закрытого ключа в текущем рабочем каталоге.
В связи с вопросом, заданным Nonameface, я хочу опубликовать небольшое руководство, которое, возможно, окажется для кого-то полезным. Многим, рассматриваемый вопрос может показаться элементарным. Я прошу не судить меня строго, поскольку этот материал адресован начинающим разработчикам.
Суть описываемой проблемы в том, что при сборке под Android, в манифест включаются все права которые только могут понадобиться приложению, разработанному в Marmalade. При этом, не выполняется никаких проверок, используются ли эти права приложением на самом деле. В результате, у пользователя, устанавливающего приложение, возникают законные вопросы: «Для чего приложение требует права на чтение и отправку SMS, если оно, совершенно очевидно, не работает с этим функционалом?».
Пользователь, совершенно резонно, может посчитать приложение небезопасным и отказаться от его установки. Давайте посмотрим, как с этим можно бороться.
Очевидно, что нам необходимо выполнить сборку, каким-то образом подменив файл AndroidManifest.xml. Для начала, нам нужно получить оригинальный AndroidManifest.xml, формируемый инструментальными средствами Maramalade. Хотя apk-файл, по сути представляет собой zip-архив и извлечь из него требуемый файл не составляет труда, задача несколько осложняется тем, что файл храниться не в текстовом, а в двоичном виде. Извлечь файл манифеста в текстовом представлении нам поможет apktool.
Выкачиваем apktool1.5.1.tar.bz2 и apktool-install-windows-r05-ibot.tar.bz2 (в случае, если используется Windows) к себе на компьютер, и распаковываем в какой-нибудь локальный каталог. Также потребуется установленная на компьютер Java (у меня установлена jdk1.6.0_23). Распаковать apk-файл можно следующей командой:
Затем, находим в созданном каталоге AndroidManifest.xml преобразованный в текстовую форму и открываем его:
Далее, мы можем отредактировать этот файл, на свой вкус, например убрав не используемые permission-ы. Для того, чтобы при последующих сборках использовалась отредактированная версия манифеста, в mkb-файл необходимо добавить следующий раздел:
Вот, в принципе, и все. После описанной замены манифеста, тестирование сборки на Android-устройстве необходимо. Вполне возможно, что какая-то часть функционала перестанет работать, либо приложение просто перестанет запускаться.
В предыдущей статье мы рассмотрели создание простого файла манифеста, давайте теперь рассмотрим как его использовать в автономных приложениях.
Использование манифеста
Самого факта создания манифеста недостаточно, чтобы браузер обращал на него внимание. Чтобы манифест имел какой-либо эффект, на него должны существовать ссылки в веб-страницах. Для этого нужно вставить в корневой элемент <html> атрибут manifest и присвоить ему в качестве значения имя файла манифеста:
Это нужно проделать для каждой страницы, входящей в автономное приложение.
Веб-сайт может иметь неограниченное количество автономных приложений при условии, что каждое из них имеет собственный манифест. Автономные приложения также могут совместно использовать некоторые ресурсы (например, таблицы стилей), но каждое приложение должно иметь свой отдельный набор веб-страниц.
Помещение манифеста на веб-сервер
Тестирование файла манифеста может оказаться сложным процессом. Небольшие ошибки могут вызывать скрытые сбои и нарушать весь процесс кэширования. Но, тем не менее, на определенном этапе файл манифеста нужно протестировать, чтобы удостовериться в том, что разработанное автономное приложение работает так, как вы ожидаете.
Не должно быть неожиданностью то обстоятельство, что автономное приложение нельзя тестировать, запуская файлы на исполнение с локального жесткого диска. Вместо этого автономное приложение нужно разместить на веб-сервере, будь то веб-сервер поставщика услуг интернета или тестовый веб-сервер разработчика, например веб-сервер IIS, встроенный в Windows.
Тестирование автономного приложения выполняется в такой последовательности:
Первым делом необходимо удостовериться в том, что для предоставления файлов манифеста в настройках веб-сервера указан MIME-тип text/cache-manifest. Если веб-сервер будет указывать какой-либо другой тип файла, включая простой текстовый файл, браузер будет полностью игнорировать манифест.
Настройка веб-серверов выполняется по-разному. Например, для веб-сервера Apache нужно будет указать следующую строчку в файле настроек .htaccess:
Рассмотрите отключение обычного кэширования для файлов манифеста. Это может быть необходимым по той причине, что веб-сервер может давать указание браузерам кэшировать файлы манифеста в течение определенного времени, точно так же, как и другие типы файлов. Такое поведение логично, но оно может вызвать большие проблемы.
Проблема состоит в том, что некоторые браузеры могут игнорировать обновленные файлы манифеста на веб-сервере и продолжать использовать старые, кэшированные файлы манифеста, вследствие чего они также будут продолжать использовать старые, кэшированные файлы веб-страниц. (Особенно грешит неохотой расставаться со старыми файлами манифеста браузер Firefox.) Во избежание этой проблемы веб-сервер необходимо настроить так, чтобы тот не указывал браузерам кэшировать файлы манифеста.
Откройте страницу в браузере, поддерживающем автономные приложения, иными словами, практически в любом браузере, за исключением Internet Explorer. Когда браузер обнаружит, что веб-страница использует манифест, он может запросить разрешение на загрузку файлов. Вероятнее всего, что такое разрешение будут требовать браузеры мобильных устройств по причине ограниченных возможностей хранения. Браузеры настольных компьютеров могут либо выдавать такой запрос, либо нет. Например, Firefox запрашивает разрешение на кэширование, a Chrome и Safari — нет:
Получив разрешение, браузер начинает кэширование файлов. Сначала загружается манифест, а потом все перечисленные в нем файлы. Процесс загрузки осуществляется в фоновом режиме, позволяя, таким образом, продолжать просмотр страницы. Этот процесс подобен тому, когда браузер загружает изображение или видео большого объема и при этом отображает остальную страницу.
Отключитесь от интернета. Если ваше приложение размещено на удаленном сервере, просто разорвите подключение. Если же приложение размещено на локальном сервере (т.е. на том же компьютере, что и браузер), остановите веб-сервер.
Чтобы продемонстрировать использование автономных приложений загрузите страницу canvas_labirint.html, на которой реализована игра, которую мы создавали ранее. В данной странице реализовано автономное управление, т.е. если вы отключитесь от интернета и обновите эту страницу, она все равно будет работать. Файл манифеста для этой страницы довольно простой, нам нужно кэшировать таблицу стилей, файл JavaScript и несколько изображений:
Обновление файла манифеста
Заставить автономное приложение работать — это только первая часть задачи. Вторая часть — обновление его содержимого.
Рассмотрим пример с лабиринтом. Если обновить файл canvas_labirint.html и перезагрузить страницу, браузер все равно будет выводить старую, кэшированную версию страницы, даже если компьютер подключен к интернету. Проблема состоит в том, что после сохранения автономного приложения в кэше браузер использует только эту кэшированную копию, игнорируя онлайновые версии соответствующих вебстраниц и не проверяя, были ли какие-либо изменения. А так как срок хранения автономного приложения в кэше никогда не истекает, браузер будет упрямо игнорировать измененные страницы на веб-сервере.
Но при этом браузер регулярно проверяет присутствие нового файла манифеста. Таким образом, можно подумать, что все, что нужно сделать для решения этой проблемы — это сохранить новый файл манифеста на веб-сервере.
Не обязательно. Чтобы инициировать обновление кэшированного автономного приложения, необходимо выполнение следующих требований:
Отсутствие кэширования файла манифеста
Если у браузера есть локальная кэшированная копия файла манифеста, он никогда не будет проверять наличие этого файла на веб-сервере. Разные браузеры подходят по-разному к вопросу кэширования файлов манифеста. Некоторые браузеры (например Chrome) всегда проверяют наличие нового файла манифеста на веб-сервере. Но Firefox следует традиционным правилам кэширования и хранит локальную копию файла манифеста в течение некоторого времени. Поэтому, чтобы избежать проблем в этой области, удостоверьтесь в том, что ваш веб-сервер явно указывает своим клиентам не кэшировать файлы манифеста.
У манифеста должна быть проставлена новая дата
Когда браузер проверяет наличие нового файла манифеста на сервере, первым делом он смотрит, изменилась ли метка времени последнего изменения. Если нет, браузер не будет загружать файл манифеста.
Содержимое файла манифеста должно быть новым
Если браузер обнаружит что содержимое нового файла манифеста не изменилось, он прекращает процесс обновления и продолжает использовать ранее кэшированную копию. Эта потенциально препятствующая плану обновления практика имеет практическую цель. Повторная загрузка кэшированного приложения занимает время и расходует пропускную способность сети, поэтому браузеры выполняют ее только в тех случаях, когда это абсолютно необходимо.
Если вы внимательно читали этот материал, то должны были заметить здесь потенциальную проблему. Что если менять содержимое файла манифеста нет надобности, т.к. не были добавлены или удалены никакие файлы, но браузер все равно нужно заставить обновить кэш автономного приложения, поскольку содержимое некоторых файлов было изменено? В таких случаях следует незначительно изменить файл манифеста, чтобы он казался новым, хотя, по сути, не является таковым. Эту задачу лучше всего реализовать, вставив в файл манифеста комментарий:
В следующий раз, когда нужно обновить кэш, просто измените номер версии, в этом примере на 1.00.002, и т.д. Таким образом мы можем заставить браузер обновить кэш и получаем способ отслеживать количество обновлений.
Новое содержимое не отображается в окне браузера сразу же после загрузки. Когда браузер обнаруживает новый файл манифеста, он загружает новые файлы в фоновом режиме и заменяет ими старые кэшированные файлы. Новое содержимое отображается, когда посетитель открывает или обновляет страницу.
Очистка кэша браузера
В процессе тестирования автономного приложения часто бывает полезным вручную очистить кэш браузера. Таким образом можно тестировать свежие обновления без необходимости изменять файл манифеста.
В браузере Firefox, чтобы просмотреть объем хранилища, занимаемого автономными приложениями, выполните команды F10 (отображает меню) --- Инструменты --- Настройки, в открывшемся диалоговом окне выберите опцию Дополнительные и перейдите на вкладку Сеть. На этой вкладке можно просматривать объем хранилища, занимаемого каждым автономным приложением и при надобности очистить кэш любого из них, выбрав требуемое приложение и нажав кнопку Удалить. В данном случае имеется только один котированный веб-сайт, в домене localhost (что представляет тестовый сервер на локальном компьютере):
Для просмотра кэшированных приложений в браузере Chrome введите chrome://appcache-internals в строку адреса:
Все браузеры разрешают очистку кэша, но каждый из них подходит к решению этой задачи по-своему. Наиболее полезные в этом отношении браузеры отслеживают объем хранилища, занимаемого каждым автономным приложением. Это позволяет определить, когда кэширование было неудачным, например, веб-сайт приложения не указывается в списке или же объем кэшированных файлов меньше, чем должен быть. Это также позволяет удалять кэшированные файлы для отдельных сайтов, не затрагивая другие.
Читайте также: