Как сгенерировать манифест visual studio
Приветствую всех, сегодня я хотел поговорить о манифестах, и как их можно использовать.
Воторой вид- это манифест приложения-который предоставляет сведение для OS, в него входит варианты развертывания сборки, а так же запрос полномочий до администратора.
Третий вид это скомпилированные типы, это метаданные и код, которые определены внутри сборки.
Четвертый вид это ресурсы-это все материалы которые вошли в сборку, это изображения, локальный текст итд.
В середине 90 при написании приложения, программы могли подменять системные библиотеки, тем самым заменять их старыми версиями, и новые программы отказывались работать. Это привело к тому что в 2000 придумали использовать манифест который шел внутри самого приложения. В нем находилось описание какая версия операционной системы требуется для работы, библиотеки, версия программы. Всю эту информацию мы могли увидеть если бы выбрали исполняемый фаил и нажали на его свойство. Так называемый манифест сборки.
А изменить все это мы могли в Свойствах проекта>Приложение>Сведения о сборке:
Все поля мы можем заполнить с нашими предпочтениями, сохранить и у нас обновиться манифест сборки, который храниться в файле AssemblyInfo.cs:
Однако это не решало не которых проблем и было придуманы манифесты приложения который сейчас просто незаменим при использовании приложений работающий с реестром и системным диском. А все дело в том что этот манифест использует Xml формат и в нем содержится информация о том как можно запустить приложение. И оптимизировать работу приложения под конкретную версию Windows вообще то в нем уже содержатся комментарии которые, достаточно раскомментировать и пересобрать свой проект с новыми возможностями.
To deploy prerequisites for your application, you can create a bootstrapper package. A bootstrapper package contains a single product manifest file but a package manifest for each locale. The package manifest contains localization-specific aspects of your package. This includes strings, end-user license agreements, and the language packs.
For more information about package manifests, see How to: Create a package manifest.
Create the product manifest
To create the product manifest
Create a directory for the bootstrapper package. This example uses C:\package.
In Visual Studio, create a new XML file called product.xml, and save it to the C:\package folder.
Add the following XML to describe the XML namespace and product code for the package. Replace the product code with a unique identifier for the package.
Add XML to specify that the package has a dependency. This example uses a dependency on Microsoft Windows Installer 3.1.
Add XML to list all the files that are in the bootstrapper package. This example uses the package file name CorePackage.msi.
Copy or move the CorePackage.msi file to the C:\package folder.
Add XML to install the package by using bootstrapper commands. The bootstrapper automatically adds the /qn flag to the .msi file, which will install silently. If the file is an .exe, the bootstrapper runs the .exe file by using the shell. The following XML shows no arguments to CorePackage.msi, but you can put command line argument into the Arguments attribute.
Add the following XML to check if this bootstrapper package is installed. Replace the product code with the GUID for the redistributable component.
Add XML to change the bootstrapper behavior depending on if the bootstrapper component is already installed. If the component is installed, the bootstrapper package does not run. The following XML checks if the current user is an administrator because this component requires administrative privileges.
Add XML to set exit codes if the installation is successful and if a reboot is necessary. The following XML demonstrates the Fail and FailReboot exit codes, which indicate that the bootstrapper will not continue installing packages.
Add the following XML to end the section for bootstrapper commands.
Move the C:\package folder to the Visual Studio bootstrapper directory. For Visual Studio 2010, this is the \Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages directory.
Example
The product manifest contains installation instructions for custom prerequisites.
When you build a project with Visual Studio, Visual Studio generates a package manifest (AppxManifest.xml), which contains information the system needs to deploy, display, or update a Universal Windows Platform (UWP) app.
There are two varieties of app package manifest files that you'll encounter if developing an app with Visual Studio
- Package.appxmanifest
This is an XML style file that developers use to configure the details of an app, such as publisher information, logos, processor architectures, etc. This is an easily configurable, temporary version of the app package manifest used during app development. - AppxManifest.xml
This file is generated by the Visual Studio build process and is based on the information in the Package.appxmanifest file. This is the final version of the app package manifest used with published and sideloaded apps. If any updates are made to the Package.appxmanifest file, you must rebuild the project to see the updates in the AppxManifest.xml file.
For an overview of the packaging process, see Package a UWP app with Visual Studio.
Validating the app manifest
Before you can publish your app, you must fix any errors that cause any of the Visual Studio validation checks to fail. When Visual Studio generates the manifest, Visual Studio validates your app in the following ways:
- Syntactic validation
Visual Studio confirms whether all data in the app manifest conforms to the app manifest schema. - Semantic validation
Visual Studio provides guidance on expected data, based on the context of the information.
If these sections don’t mention the field that you’re looking for, it’s generated from either data that may have been configured separately or a default value from the manifest schema.
Generating the manifest content
Visual Studio populates the fields in the following tables when it generates the AppxManifest.xml file for the app package.
Identity
The Identity section of the app manifest contains the following fields.
- By default, the value of this field is a generated GUID.
- If you associate the app with the Microsoft Store, or if you invoke the Store -> Create App Packages. command and then sign in with a developer account, the value of this field is retrieved from the associated app in the Microsoft Store or Partner Center.
- If you invoke the Store -> Create App Packages. command but do not sign in with a developer account, the value of this field is taken from the source manifest.
- By default, the value of this field is your user name.
- If you associate the app with the Microsoft Store, or if you invoke the Store -> Create App Packages. command and then sign in with a developer account, the value of this field is the publisher associated with the account.
- If you invoke the Store -> Create App Packages. command but do not sign in with a developer account, the value of this field matches the subject field of the test certificate you used to sign the app package.
Here's an example of the Identity output XML:
Properties
The Properties section of the app manifest contains the fields in the following table.
- By default, the value of this field is your user name.
- If you associate the app with the Microsoft Store, or if you invoke the Store -> Create App Packages. command and then sign in with a developer account, tha value of this field matches the PublisherDisplayName string associated with your developer account.
- If you invoke the Store -> Create App Packages. command but do not sign in with a developer account, the value of this field is your user name, unless you specify otherwise in the Package.appxmanifest file.
- By default, the value of this field is the name of the project.
- If you associate the app with the Microsoft Store, or if you invoke the Store -> Create App Packages. command and then sign in with a developer account, the value of this field is populated according to the following rules:
- If you specify this value in the source manifest and the value starts with @ (which indicates that you want to localize this value), the value of this field will match what you specified.
- If the selected app has only one name, the value will be that name.
- If the selected app has multiple names but the source manifest isn’t localized, the value is set to the display name in the source manifest. Otherwise, the value is set to the first reserved name.
Here's an example of the Properties output XML:
Application
A app manifest can contain multiple Application elements, each of which has a display name that appears on the tile in the client. The Application section of the app manifest contains the fields in the following table.
- By default, the value of this field is the name of the project.
- If you associate the app with the Microsoft Store, or if you invoke the Store -> Create App Packages. command and then sign in with a developer account, the value of this field is the app name for the selected app if the /Properties[@DisplayName] and the /Applications/Application[@DisplayName] in the source manifest match. Otherwise, the value remains the same as in the source manifest.
- If you invoke the Store -> Create App Packages. command but do not sign in with a developer account, the value of this field is the same as in the source manifest.
Example Application output:
PackageDependency
The PackageDependency section contains all the Windows component library dependencies for this package. For example, if your project has a reference to WinJS, Visual Studio retrieves the package identity information of the dependencies when the manifest is generated. Visual Studio then populates this section with the Name and MinVersion fields for each dependent package.
In a native C++ project, Visual Studio will add a reference to the Visual C/C++ Runtime:
Windows Runtime registration extensions
You can implement Windows Runtime components for your apps, but you'll need to register those components with the operating system for them to run correctly. To register a Windows Runtime component, you must put the registration information in the WinMD files and in the app manifest. If a project implements a Windows Runtime component, the build output of the project will contain a WinMD file. Visual Studio extracts the Windows Runtime registration information from the WinMD file and generates the appropriate Extension elements in the app manifest.
The system supports two forms of servers: .dll servers (in-process) and .exe servers (out-of-process). These servers require similar but different registration information that must be copied into the app manifest. Visual Studio supports generating manifest only for .dll servers, and the DLLServer extension is required to register .dll servers. The following values in the app manifest are taken from the WinMD files to construct the DLLServer Extension:
- DllPath
- ActivatableClassId
- ThreadingModel
- ActivatableClass (ActivatableClassId attribute)
Here's an example of the output XML:
For more information on this topic, see Windows Runtime components.
Resources
The Resources section contains an entry for each language that the application supports. You must have at least one resource language specified in the app manifest. Visual Studio automatically generates the list of supported languages based on the localization information in the project. The resource language token "x-generate" that's used in the source manifest file (Package.appxmanifest) is replaced with the actual language code when the manifest is built. Here's an example of the output XML:
при построении проекта с Visual Studio Visual Studio создает манифест пакета (AppxManifest.xml), который содержит сведения, необходимые системе для развертывания, вывода или обновления приложения универсальная платформа Windows (UWP).
Существует два вида файлов манифеста пакета приложения, которые могут возникнуть при разработке приложения с Visual Studio
- Package.appxmanifest
Это XML-файл стиля, используемый разработчиками для настройки сведений о приложении, таких как сведения об издателе, логотипы, архитектуры процессоров и т. д. Это легко настраиваемая временная версия манифеста пакета приложения, используемая во время разработки приложения. - AppxManifest.xml
этот файл создается Visual Studio процессом сборки и основывается на информации в файле Package. appxmanifest. Это окончательная версия манифеста пакета приложения, используемого с опубликованными и загруженные неопубликованные приложениями. Если в файл Package. appxmanifest вносятся какие либо обновления, необходимо перестроить проект, чтобы просмотреть обновления в файле AppxManifest.xml.
Общие сведения о процессе упаковки см. в статье Упаковка приложения UWP с помощью Visual Studio.
Проверка манифеста приложения
- Синтаксическая проверка
Visual Studio проверяет, соответствуют ли все данные в манифесте приложения схеме манифеста приложения. - Семантическая проверка
Visual Studio предоставляет рекомендации по ожидаемым данным на основе контекста сведений.
Если в этих разделах не упоминается искомое поле, оно формируется из данных, которые могут быть настроены отдельно, или по умолчанию из схемы манифеста.
Создание содержимого манифеста
Visual Studio заполняет поля в следующих таблицах при формировании файла AppxManifest.xml для пакета приложения.
Идентификация
Identity Раздел манифеста приложения содержит следующие поля.
- По умолчанию значением этого поля является созданный GUID.
- если вы связываете приложение с Microsoft Store или вызываете команду Store- > Create app packages. , а затем выполняете вход с помощью учетной записи разработчика, значение этого поля извлекается из связанного приложения в Microsoft Store или в центре партнеров.
- Если вы вызываете команду Store- > CREATE App Packages. , но не входите с помощью учетной записи разработчика, значение этого поля берется из манифеста источника.
- По умолчанию значением этого поля является имя пользователя.
- если вы связываете приложение с Microsoft Store или вызываете команду Store- > Create app packages. , а затем выполняете вход с помощью учетной записи разработчика, значением этого поля будет издатель, связанный с учетной записью.
- Если вы вызываете команду Store- > CREATE App Packages. , но не выполняете вход с помощью учетной записи разработчика, значение этого поля совпадает с полем Subject тестового сертификата, который использовался для подписания пакета приложения.
Свойства
Properties Раздел манифеста приложения содержит поля, приведенные в следующей таблице.
- По умолчанию значением этого поля является имя пользователя.
- если вы связываете приложение с Microsoft Store или вызываете команду Store- > Create app packages. , а затем выполняете вход с помощью учетной записи разработчика, tha значение этого поля соответствует строке PublisherDisplayName, связанной с вашей учетной записью разработчика.
- Если вы вызываете команду Store- > CREATE App Packages. , но не входите с помощью учетной записи разработчика, значение этого поля будет иметь имя пользователя, если в файле Package. appxmanifest не указано иное.
- По умолчанию значением этого поля является имя проекта.
- если вы связываете приложение с Microsoft Store или вызываете команду Store- > Create app packages. , а затем выполняете вход с помощью учетной записи разработчика, значение этого поля заполняется в соответствии со следующими правилами:
- Если указать это значение в исходном манифесте, а значение начинается с @ (что означает, что вы хотите локализовать это значение), значение этого поля будет соответствовать указанному.
- Если выбранное приложение имеет только одно имя, значением будет это имя.
- Если выбранное приложение имеет несколько имен, но исходный манифест не локализован, в качестве значения задается отображаемое имя в исходном манифесте. В противном случае, значение равно первому зарезервированному имени.
Ниже приведен пример Properties выходного XML.
Развертывание
Манифест приложения может содержать несколько Application элементов, каждый из которых имеет отображаемое имя, отображаемое на плитке в клиенте. Application Раздел манифеста приложения содержит поля, приведенные в следующей таблице.
- По умолчанию значением этого поля является имя проекта.
- если вы связываете приложение с Microsoft Store или вызываете команду Store- > Create app packages. , а затем выполняете вход с помощью учетной записи разработчика, значение этого поля является именем приложения для выбранного приложения, если /Properties[@DisplayName] и /Applications/Application[@DisplayName] в исходном манифесте совпадают. В противном случае, значение останется тем же, что и в манифесте источника.
- Если вы вызываете команду Store- > CREATE App Packages. , но не входите с помощью учетной записи разработчика, значение этого поля совпадает с исходным манифестом.
Пример Application выходных данных:
PackageDependency
PackageDependency раздел содержит все зависимости библиотеки компонентов Windows для этого пакета. например, если проект содержит ссылку на WinJS, Visual Studio извлекает сведения об удостоверении пакета для зависимостей при создании манифеста. Visual Studio заполнит этот раздел Name полями и MinVersion для каждого зависимого пакета.
в проекте C++ для машинного кода Visual Studio добавит ссылку на среду выполнения Visual C/C++:
модули регистрации среда выполнения Windows
вы можете реализовать среда выполнения Windows компоненты для приложений, но для их правильной работы необходимо зарегистрировать эти компоненты в операционной системе. чтобы зарегистрировать компонент среда выполнения Windows, необходимо разместить сведения о регистрации в файлах WinMD и в манифесте приложения. если проект реализует компонент среда выполнения Windows, выходные данные сборки проекта будут содержать WinMD-файл. Visual Studio извлекает сведения о регистрации среда выполнения Windows из WinMD-файла и создает соответствующие Extension элементы в манифесте приложения.
Система поддерживает два типа серверов: DLL-серверы (внутрипроцессные) и EXE-серверы (внепроцессные). Для этих серверов требуются похожие, но различные сведения о регистрации, которые необходимо скопировать в манифест приложения. Visual Studio поддерживает создание манифеста только для DLL-серверов, для регистрации DLL-серверов требуется расширение DLLServer. Следующие значения в манифесте приложения взяты из файлов WinMD для построения расширения DLLServer.
- DllPath.
- ActivatableClassId.
- ThreadingModel.
- ActivatableClass (атрибут ActivatableClassId).
Ниже приведен пример выходного XML.
дополнительные сведения об этом разделе см. в разделе среда выполнения Windows components.
Ресурсы
Resources Раздел содержит запись для каждого языка, поддерживаемого приложением. Необходимо указать по крайней мере один язык ресурсов в манифесте приложения. Visual Studio автоматически создает список поддерживаемых языков на основе сведений о локализации в проекте. Маркер языка ресурсов "x-Generate", используемый в исходном файле манифеста (Package. appxmanifest), заменяется фактическим кодом языка при сборке манифеста. Ниже приведен пример выходного XML.
Сборки имеют следующие составляющие:
Манифест, который содержит метаданные сборки
Метаданные типов. Используя эти метаданные, сборка определяет местоположение типов в файле приложения, а также места размещения их в памяти
Все эти компоненты могут находиться в одном файле, и тогда сборка представляет один единственный файл в формате exe или dll.
Но также может быть, что эти компоненты хранятся в отдельных файлах. Например, есть основной файл exe, который имеет метаданные сборки и типов и который использует дополнительные файлы ресурсов - различные изображения, звуковые файлы, вспомогательные модули, элементы интерфейса, локализованные для различных культур.
Манифест сборки
Ключевым компонентом сборки является ее манифест . Если у сборки отсутствует манифест, то заключенный в ней код MSIL выполняться не будет. Манифест может находиться в одном файле с исполняемым кодом сборки, а может размещаться и в отдельном файле.
Манифест хранит следующие данные:
Номер версии : основной и дополнительный номера. Используется для управления версиями
Язык и региональные параметры : информация о языке и региональных параметрах, которые поддерживает сборка
Информация о строгом имени : открытый ключ издателя
Список всех файлов сборки : хэш и имя каждого из входящих в сборку файлов
Список ссылок на другие сборки , которые использует текущая сборка
Список ссылок на типы , используемые сборкой
Таким образом, манифест позволяет системе определить все файлы, входящие в сборку, сопоставить ссылки на типы, ресурсы, сборки с их файлами, управлять контролем версий.
Атрибуты сборки
По умолчанию Visual Studio при создании проекта добавляет файл AssemblyInfo.cs, который можно найти в узле Properties:
Смысл этого файла состоит в том, что он задает настройки манифесту сборки. Через атрибуты типа [assembly: AssemblyVersion("1.0.0.0")] можно установить значения в манифесте. Префикс assembly: перед атрибутом указывает на то, что это атрибут уровня сборки, в данном случае атрибут номера версии сборки.
В принципе, исходя из названия, я думаю, предназначение многих атрибутов итак понятно:
AssemblyCompany : название компании
AssemblyConfiguration : конфигурация сборки (Retail или Debug)
AssemblyCopyright : авторское право на программу
AssemblyDefaultAlias : псевдоним по умолчанию, используемый при ссылке на данную сборку из других сборок
AssemblyDescription : краткое описание сборки
AssemblyProduct : информация о продукте
AssemblyTitle : название сборки как информационного продукта
AssemblyTrademark : сведения о торговой марке
AssemblyCulture : задает язык и региональные параметры, поддерживаемые сборкой (например, установка русской культуры: [assembly:AssemblyCultureAttribute("ru")] )
AssemblyInformationalVersion : полная версия сборки
AssemblyVersion : версия сборки
AssemblyFileVersion : номер версии файла Win32. По умолчанию совпадает с версией сборки.
Также есть графический способ определения информации о сборке. Для этого нажмем в окне Solution Explorer (Обозреватель решений) на название проекта правой кнопкой мыши и выберем в появившемся меню пункт Properties (Свойства). В открывшемся окне нажмем на кнопку Assembly Information. , и нам предстанет окно изменения атрибутов:
После любых изменений, произведенных в этом окне, соответствующей информацией будет автоматически обновлен и файл AssemblyInfo.cs.
Читайте также: