Как создать windows installer
В этой статье показано, как вручную создать файл установщика приложения, который определяет связанный набор с возможностями автообновления и восстановления. Связанный набор — это не один объект, а сочетание основного и дополнительных пакетов.
Чтобы получить возможность установить связанный набор как один объект, необходимо указать основной и дополнительные пакеты как один объект. Для этого необходимо создать XML-файл с расширением appinstaller , чтобы определить связанный набор. Установщик приложений использует файл *. appinstaller и позволяет пользователю установить все определенные пакеты одним щелчком мыши.
Во время развертывания файл установщика приложения будет:
- пакет приложения Windows, на который ссылается URI атрибут элемента , проверит Name , а также Publisher Version атрибуты целевого Windows пакета приложения. если элемент пакета или удостоверения в манифесте пакета приложения Windows не совпадает, установка завершится ошибкой.
- Создайте ссылку на обновления и исправьте URI для семейства пакета.
Инструкции по созданию файла Установщика приложений.
Чтобы распространить связанный набор как одну сущность, необходимо создать файл установщика приложения, содержащий элементы, необходимые для схемы установщика приложений.
Пример файла установщика приложения
Выполнив приведенные выше действия, вы успешно создали файл установщика приложения, который будет выглядеть следующим образом:
Шаг 1. Создание файла *.appinstaller
С помощью текстового редактора (Notepad.exe) создайте новый файл с расширением имени файла *. AppInstaller
Руководство.
- Откройте меню "Пуск".
- Введите следующее: notepad.exe .
- Откройте меню файл .
- В раскрывающемся меню выберите команду Сохранить как .
Шаг 2. Добавление базового шаблона
Включите AppInstaller элемент в файл установщика приложения, указывая версию, путь и сетевое расположение файла установщика приложения. сведения в AppInstaller элементе будут использоваться при установке связанных приложений Windows.
| Элемент | Описание |
|---|---|
| xmlns | Пространство имен XML |
| Version | Версия файла установщика приложения в нотации с четырьмя точками (1.0.0.0). |
| URI | Путь URI к текущему файлу установщика приложения, доступный для устройства. |
Руководство.
Откройте файл, созданный на шаге 1.
Скопируйте следующее XML-содержимое в *. Файл AppInstaller .
Обновление Version атрибута с помощью версии файла установщика приложения
Обновите URI атрибут с помощью сетевого расположения, в котором находится этот * URI будет доступен из.
Шаг 3. Добавление сведений об основном пакете
<MainPackage> и <MainBundle> используются для задания основного Windows приложения, которое будет установлено с помощью файла установщика приложения. <MainPackage> используется, если установщик Windows приложения имеет значение * <MainPackage> или *. appx. используйте, <MainBundle> когда установщик приложения Windows является пакетным установщиком Windowsного приложения с расширением * <MainBundle> или *. appxbundle.
| Элемент | Описание |
|---|---|
| Имя | Имя основного приложения, которое будет распространяться через файл установщика приложения. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
| Publisher | каноническое имя сертификата издателя, используемого для подписания основного установщика Windows приложения. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher . |
| Версия | версия основного установщика приложения Windows в нотации с четырьмя точками (1.0.0.0). Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version . |
| ProcessorArchitecture | архитектура, на которой устанавливается основной установщик приложения Windows. |
| URI | путь URI к основному установочному носителю Windows приложения. |
Сведения в атрибуте <MainBundle> или <MainPackage> должны совпадать с элементом <MainBundle> в манифесте пакета приложений или пакета приложения соответственно.
установщик приложения Windows
Если основным пакетом приложения является файл. msix или. appx, используйте <MainPackage> , как показано ниже. Обязательно включите ProcessorArchitecture, так как он обязателен для пакетов, не относящихся к пакету.
установщик пакета приложений Windows
Если основным пакетом приложения является msixbundle или appxbundle или файл, используйте <MainBundle> вместо, <MainPackage> как показано ниже. Для пакетов ProcessorArchitecture не требуется.
Шаг 4. Добавление дополнительных пакетов
Как и атрибут основного пакета приложений, если дополнительный пакет может являться пакетом приложения или пакетом приложений, дочерний элемент с атрибутом <OptionalPackages> должен являться <Package> или <Bundle> . Сведения о пакете в дочерних элементах должны соответствовать элементу идентификатора в манифеста пакета приложений или пакета приложения.
| Элемент | Описание |
|---|---|
| Имя | Имя дополнительного приложения, которое будет распространяться через файл установщика приложения. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
| Publisher | каноническое имя сертификата издателя, используемого для подписи необязательного установщика Windows приложения. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher . |
| Версия | версия необязательного установщика Windows приложения в нотации с четырьмя точками (1.0.0.0). Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version . |
| ProcessorArchitecture | архитектура, на которую устанавливается необязательный установщик приложения Windows. |
| URI | путь URI к основному установочному носителю Windows приложения. |
Шаг 5. Добавление зависимостей
В элементе зависимостей можно указать требуемые пакеты платформы для основного пакета или дополнительных пакетов.
| Элемент | Описание |
|---|---|
| Имя | Имя приложения зависимости, которое распространяется в файле установщика приложения. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
| Publisher | каноническое имя сертификата издателя, используемого для подписания Windows установщика приложения зависимостей. Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher . |
| Версия | версия установщика зависимостей Windows приложения в нотации с четырьмя точками (1.0.0.0). Его можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version . |
| ProcessorArchitecture | архитектура, на которой устанавливается установщик приложения зависимостей Windows. |
| URI | универсальный код ресурса (URI) для установочного носителя приложения зависимости Windows. |
Шаг 6. Добавление параметра обновления
В файле Установщика приложений можно также указать параметр обновления, чтобы связанные наборы автоматически обновлялись при публикации нового файла Установщика приложений. Параметр является необязательным элементом. В параметре OnLaunch указывает, что проверки обновлений должны выполняться при запуске приложения, а хаурсбетвинупдатечеккс = "12" указывает, что проверка обновлений должна выполняться каждые 12 часов. Если параметр HoursBetweenUpdateChecks не задан, интервал проверки обновлений по умолчанию — 24 часа. дополнительные типы обновлений, например фоновые обновления, можно найти в схемеПараметры обновления. Дополнительные типы обновлений для запуска, такие как обновления с запросом, можно найти в схеме OnLaunch.
| Элементы | Описание |
|---|---|
| хаурсбетвинупдатечеккс | определяет минимальный зазор в Windows проверки обновлений приложения. |
| упдатеблокксактиватион | Определяет интерфейс при проверке обновления приложения. |
| шовпромпт | Определяет, отображается ли окно при установке обновлений и когда выполняется проверка обновлений. |
шаг 7. добавление Параметры автоматического обновления
следующие параметры доступны только при использовании схемы 2021 в сборке Windows Insider Windows 10.
Windows приложения, установленные с помощью файла установщика приложения, по умолчанию обновляют Windows приложения из URI установщика приложений, адхереинг к конфигурациям, заданным на предыдущем шаге. URI обновления, настроенные на этом шаге, будут действовать как резервные URI, которые можно использовать, если исходный URI установщика приложения больше недоступен. для любого Windows приложения можно настроить не более 10 URI обновления.
URI обновления должен быть предназначен для файлов установщика приложений.
Эти параметры работают, только если схема настроена как 2021 или более новая.
шаг 8. добавление Параметры автоматического восстановления
следующие параметры доступны только при использовании схемы 2021 в сборке Windows Insider Windows 10.
Windows приложения, установленные на устройстве, могут поддерживать автоматическое восстановление приложения Windows, когда оно становится незаконным. исходный установщик, который будет использоваться для восстановления Windows приложения, можно настроить с помощью <RepairURIs> свойства. приложение Windows попытается восстановиться на основе URI установщика приложения, если он недоступен, Windows приложение будет использовать универсальный код ресурса (uri) восстановления для идентификации источника исправления. для любого Windows приложения можно настроить не более 10 URI восстановления.
универсальный код ресурса (URI) восстановления может ориентироваться Windows файлы установщика приложения или приложения. этот параметр не требует, чтобы Windows приложение было установлено с помощью файла установщика приложения.
Полные сведения о схеме XML см. в разделе Справочник по файлу Установщика приложений.
тип файла установщика приложений новый в Windows 10, версия 1709 (Windows 10 Fall Creators Update). развертывание Windows 10 приложений с помощью файла установщика приложения в предыдущих версиях Windows 10 не поддерживается. элемент хаурсбетвинупдатечеккс доступен начиная с Windows 10 версии 1803.
Технология Windows Installer (MSI) является стандартом де-факто в мире системных администраторов, занимающихся распространением и поддержкой программного обеспечения для десктопных и серверных версий Windows. Формат MSI поддерживается всеми крупнейшими системами управления конфигурациями (Microsoft SCCM, CA Unicenter и многими другими), а для некоторых систем распространения ПО — является единственным поддерживаемым форматом.
Мой опыт работы с этой технологией — как теоретический, так и практический — приобретен за время работы в компании «Инфопульс Украина» и связан с созданием MSI-пакетов и подготовкой готовых MSI-пакетов к автоматической установке в корпоративной среде.
Зачем это вам?
Если вы занимаетесь централизованной установкой приложений в сетях Windows, знание формата MSI и умение создавать и редактировать пакеты в этом формате вам может здорово пригодиться при подготовке пакета к развертыванию и диагностике проблем. В Европе и США технология Windows Installer востребована многими крупными заказчиками, поэтому знание MSI может быть плюсом для системного администратора при трудоустройстве.
Что нужно знать и уметь перед началом изучения?
Ничего сложного. Если у вас есть опыт администрирования и поддержки небольшой (а лучше большой, иерархической) сети Windows-машин, вероятнее всего вы уже сталкивались с основными вопросами и понятиями, которые вам понадобятся. Перед тем, как начать, убедитесь, что вы хорошо понимаете структуру файловой системы Windows, структуру профиля пользователя и структуру реестра, знаете что такое процессы и службы в Windows, умеете управлять учетными записями пользователей и знаете где находятся журналы событий. Для того, чтобы научиться создавать пакеты MSI, вам совсем необязательно иметь опыт разработчика, хотя конечно лучше если такой опыт у вас есть. И совсем не обязательно уметь писать запросы на SQL, хотя это тоже может пригодиться (ведь каждый MSI-файл — это небольшая реляционная база данных). Но обязательно нужно уметь читать и понимать техническую документацию на английском, без этого скорее всего ничего не получится. При изучении теории (и при создании пакетов на практике) постарайтесь хотя бы на первых порах строго следовать стандартам Windows Installer, избегая вспомогательных утилит типа InstallShield/InstallScript, так вы лучше поймёте как правильно создать MSI-пакет.
Готовим песочницу и начинаем практику
Начать нужно с установки и настройки виртуальной машины. В процессе обучения вам придется немало поэкспериментировать, поэтому лучше сделать это в песочнице. Если нужны бесплатные продукты — устанавливаем VirtualBox или VMWare Player (для профессиональных задач их функционала может быть недостаточно, но для обучения — вполне подойдет). В виртуальной машине, естественно, нужно установить Windows на ваш выбор (XP и выше).
Если у вас уже есть опыт работы с утилитами от Sysinternals — прекрасно. Если нет — самое время восполнить пробел. Нам понадобятся минимум две: для отслеживания файловой и реестровой активности приложения при установке или во время его работы — Process Monitor, для запуска инсталляции от имени учетной записи LocalSystem — PsExec. Попрактикуйтесь использовать эти утилиты на простом приложении типа notepad (с какими ресурсами работает notepad при открытии файла, при сохранении файла; запустите notepad от имени пользователя LocalSystem, поэкспериментируйте с сохранением файлов и установкой файловых ассоциаций), в дальнейшем эти навыки пригодятся.
Установите Panda QuickShot или другой софт для сравнения состояний системы. Разберитесь с основным функционалом, научитесь отслеживать файловые и реестровые изменения в системе при установке нового приложения или изменении параметров системы (самое простое — зарегистрируйте новую файловую ассоциацию для notepad, измените обои рабочего стола и отследите где хранятся эти настройки). Подойдите к этому творчески, поле для экспериментов обширное.
Скачайте MSI-инсталлятор какого-нибудь несложного приложения (например, Orca, InstEd или Firefox). Установите пакет на виртуальной машине, с помощью описанных выше утилит изучите устанавливаемые им ресурсы. Научитесь пользоваться командной строкой Windows Installer (msiexec /?), поэкспериментируйте с различными опциями установки и сравните результат. Выполните удаление приложения из командной строки, установите пакет в автоматическом (silent) режиме.
Установите InstEd или Orca на хост-машине. Откройте MSI-пакет, который вы устанавливали на виртуальной машине, с помощью одной из этих утилит. Сравните записи основных таблиц в MSI-пакете (File, Directory, Registry) с ресурсами (файлы, папки, ключи реестра), установленными этим пакетом на вашей виртуальной машине (результат сравнения снимков состояний с помощью Panda QuickShot).
Немного теории
- Таблица Property, код продукта (ProductCode), код пакета (PackageCode), стандартные свойства в MSI;
- Таблица Upgrade и код обновления (UpgradeCode);
- Таблицы Feature, Component и их назначение;
- Таблицы Directory, File, Registry, Shortcut; приложения, поставляемых с MSI-пакетом, таблица Media; , их создание и применение из командной строки.
Обзор утилит и документации
Бесплатно можно использовать простые редакторы MSI-файлов с ограниченным функционалом — здесь упоминания заслуживают классическая Orca от Microsoft и довольно удобный InstEd. Эти редакторы позволяют вносить небольшие изменения в готовые MSI-файлы, создавать и применять трансформы, но создавать в них MSI-пакеты с нуля довольно непросто (а для больших пакетов — и вовсе не имеет смысла). Но если вы действительно хотите изучить технологию MSI, вам просто необходимо собрать пару простых пакетов в InstEd или Orca и выполнить их валидацию на соответствие стандарту Windows Installer.
Специализированные утилиты для выполнения setup capture (создания или конвертирования установочных пакетов из так называемых «старых форматов"» в формат MSI с использованием сравнения «снимков» системы до и после установки приложения или мониторинга изменений в системе «на лету») — бесплатный AppDeploy Repackager, или более серьезный MSI Generator. MSI-пакетам, созданным с использованием этих утилит, может потребоваться некоторая доработка, которую можно выполнить с помощью редактора MSI.
Серьёзные полнофункциональные (и весьма дорогие) IDE, обеспечивающие поддержку полного цикла работ с MSI-пакетами — если вы будете заниматься технологией MSI профессионально, вам скорее всего не обойтись без этих программ. В этом сегменте до недавнего времени доминировали два продукта — AdminStudio от Flexera и Wise Package Studio от Symantec, но недавно Symantec объявил о прекращении работ по развитию Wise Package Studio, и рынок переходит в руки Flexera. Кроме работы с MSI, AdminStudio позволяет работать с виртуальными пакетами форматов Microsoft App-V, VMware Thin App и Citrix XenApp. Для ознакомительных целей доступна пробная 21-дневная версия.
Отдельно стоит упомянуть WIX (Windows Installer XML) — набор утилит для создания MSI-файлов из XML-описаний. Этот проект был выпущен «Майкрософтом» под открытой лицензией Common Public License, поддерживает интерфейс командной строки и может использоваться для автоматизации создания версий инсталляционных пакетов. Хорошее описание есть на Хабре.
Большинство инсталляторов создаётся при помощи разных утилит (WiX, Inno Setup, Install Shield и т.д.). Меня интересует вопрос создания инсталлятора с собственным UI, как это сделано, например, у Kaspersky Anti-Virus и у Visual Studio.
Для создания кастомного UI через WIX можно использовать Burn / BootstrapperApplication - стандартный способ для создания оберток поверх MSI.
Пример для WPF есть в src-пакете WiX, в папке src\Setup\WixBA . Прикручивается (судя по документации) примерно так:
В bundle.wxs (есть в стандартном шаблоне WiX для VS) добавляется
Сам по себе кастомный UI - это просто класс-наследник BootstrapperApplication в сборке, отмеченной атрибутом BootstrapperApplicationAttribute .
Более подробные примеры:
47k 11 11 золотых знаков 74 74 серебряных знака 143 143 бронзовых знака Комментарии не предназначены для расширенной дискуссии; разговор перемещён в чат.Создавать инсталлятор полностью с нуля (без использования модели Windows Installer), только ради красивого интерфейса, наверное не стоит. Установить приложение легко, сложнее корректно его удалить во всех ситуациях, не оставив мусора и не запоров настройки системы - особенно если программа меняет ассоциации файлов, устанавливает свои расширения проводника, регистрирует COM-объекты и т.п.
Инсталлятор в Windows Installer состоит из двух частей:
Файл *.MSI - это база данных, которая содержит информацию о структуре приложения, его файлы (либо информацию, где они лежат, если они не встроенные), перечень изменений в реестре и др. Его можно создавать с помощью стандартной утилиты Orca.exe из Windows SDK или с помощью какой-либо сторонней утилиты.
Приложение-обертка (setup.exe), которое проверяет наличие необходимой версии Windows Installer, при необходимости предлагает пользователю ее установить, а затем запускает установку самой программы с помощью функции MsiInstallProduct.
Они могут по разному между собой соотноситься (MSI внутри EXE, MSI в папке рядом с EXE, EXE скачивает MSI с интернета), но суть одинакова.
Приложение-обертка может использовать либо стандартный интерфейс Windows Installer, либо отключить его и зарегистрировать свой (вызовами MsiSetInternalUI / MsiSetExternalUI перед MsiInstallProduct ). Можно использовать любую GUI-технологию для создания своего интерфейса, а затем передать параметры в MSI с помощью строки свойств типа TARGETDIR="C:\Program Files\MyApp" ADDLOCAL="Feature1, Feature2" .
Здравствуйте. Сегодня хочу поднять тему, которая успела наболеть. Не знаю, как вы, а я в последнее время по работе довольно часто сталкиваюсь с проблемами установщика Windows – ошибками msi. Причем, данный вопрос бывает актуальным как для старой доброй Windows XP, так и для относительно «свежих» Windows 7 и Windows 8. Давайте разберем этот вопрос подробно, так как тема очень серьезная и если проблема возникла один раз, то поверьте, жизнь она вам осложнит – однозначно.
Команда «scan now»
Если в результате действия вирусов или системных сбоев были повреждены какие-либо важные системные файлы, отвечающие за Installer, вы можете воспользоваться специальной командой для консоли выявления и устранения ошибок. Необходимо проделать следующее:
-
Вызовите диалоговое окно «Выполнить» с помощью комбинации «Win» + «R».
После этого попробуйте снова вызвать Installer, запустив установку какого-нибудь приложения. Если проблема не разрешилась – переходите к следующему пункту руководства.
Регистрируем заново установщик Windows
Следующий способ и решение задачи, если не удается получить доступ к службе установщика Виндовс, основан на изменении параметров реестра. При входе в настройки реестра нужно помнить, что, если вы внесете неправильно какой-либо параметр или настройку это может стать причиной серьезных сбоев в операционной системе. Поэтому внимательно следите за инструкциями и осторожно вносите правки в реестре. Хорошей практикой будет создание резервной копии реестра Microsoft Windows. Это даст вам возможность при неправильных правках и проблемах с ОС при настройке вернуть их в исходное положение. Как сделать резервную копию можно посмотреть на официальном сайте Microsoft.
Помочь решить проблему может перерегистрация службы. При сбоях и неправильной работе системы в этой службе могут возникнуть ошибки, из-за чего мы сталкиваемся с данной проблемой.
- Запускаем командную строку, чтобы это сделать, нажмите WIN+R.
- В окне введите команду msiexec /unregister и нажмите ввод. Если после исполнения работы строки ничего не произошло – так и должно быть.
Команда msiexec /unregister
Команда msiexec /regserver
Это может быть полезным: Ошибка System_thread_exception_not_handled на Windows 10, что делать?
Диспетчер служб
Возможно, Installer не работает из-за отключенной службы, которая за него отвечает. Попробуйте открыть менеджер и включить ее. Если вы не знаете, как это делать – следуйте инструкции:
- Вызовите меню «Пуск».
- Запустите Панель Управления.
- Откройте раздел «Система и безопасность».
- Перейдите в категорию, которая называется «Администрирование».
- Запустите утилиту «Службы».
Если в представленном списке нужного элемента нет, вызовите командную строку. Как это сделать, описывается выше, в предыдущем разделе руководства. В консоли требуется ввести команду «net start MSIServer» и нажать Энтер. Если никаких проблем не возникнет, вы увидите надпись «Установщик Windows успешно запущен».
Что же это за файлы такие, имеющие расширение msi?
Этот файл установочного пакета, с помощью которого инсталлируется программное обеспечение, и который использует службу установщика Windows. Свое название расширение msi взяло от «Microsoft Installer», как раньше называлась версия установщика Windows. Такой файл содержит в себе полный сценарий установки программного продукта, вспомогательные компоненты, библиотеки и, в большинстве случаев, все установочные файлы, сжатые в cab-архивы. Можно долго обсуждать все достоинства и недостатки в работе Windows Installer, но придется все же принять его «как есть», а на некоторые неполадки в работе будем грамотно и адекватно реагировать. Ошибки могут возникать как в работе службы, так и по причине самих msi файлов.
Вот, что иногда случается: Error 1305: Error reading from file и далее система предлагает мне убедиться, а действительно ли был файл установщика, который я запускал. Поначалу звучит как минимум странно. Но, читая дальше послание системы, понимаю, что мне предлагают убедиться не только в наличии самого файла, но и в моих правах на доступ к нему. Как оказалось, это не я, а Windows Installer был обделен доступом к файлу, отсюда и проблема.
Разрешается этот вопрос вовсе не сложным способом. Давайте для начала убедимся, есть ли у системы к файлу полный доступ, для чего в «Свойствах» файла зайдем на вкладку «Безопасность» и найдем пользователя «System (Система)».
Более чем уверен, что там вы его не обнаружите, так что добавляем сами – жмем на «Изменить», потом на «Добавить» и вписываем имя: «Система» (или же System, в случае англоязычной версии системы),
после чего жмем на «Проверить имена» (строчка становится подчеркнутой). Подтверждаем – ОК и ставим отметку в чекбоксе «Полный доступ», опять подтверждаем.
Жмем на «Дополнительно», далее – «Изменить разрешения» – «Добавить разрешения», наследуемые от родительских объектов и все подтверждаем трижды. Таким образом, от этой ошибки установщика мы избавились, и больше она нас не побеспокоит в процессе установки. Хотя более разумно и предусмотрительно было бы добавить права полного доступа системы на всю папку с содержимым, из которой по обыкновению происходит инсталлирование программного обеспечения (как в моем случае папка «Install»).
Если на вашем компьютере имеется операционная система Windows ХР, а в «Свойствах папки» включен «простой общий доступ к файлам», вы не увидите вкладку «Безопасность» в свойствах файла. В таком случае вам следует зайти в «Свойства папки» и снять отметку в чекбоксе «Использовать простой общий доступ к файлам». Также этой вкладки вы рискуете не обнаружить в разных «сборках» и «облегченных версиях» как Windows XP, так и Windows 7. Чтобы таки зайти на эту вкладку, придется загрузиться в Safe mode (Безопасном режиме) и войти под учетной записью администратора.
Еще проблему с Windows Installer можно избежать, запуская установку приложений с отключенной программой-антивирусом, с правами администратора, а также в режиме совместимости (вкладка «Совместимость» в свойствах msi-файла, ставим галочку в соответствующем чекбоксе).
Также проблемы могут быть при попытке установить программу со съемного носителя, флешки, например (запрет на такие действия можно сделать в настройках операционной системы) – просто скопируйте установочный файл в удобное место на жестком диске. Еще вариант решения проблемы – создайте новую папку под любым понравившимся именем и скопируйте в нее установочный пакет, оттуда и запускайте установку – бывает полезным при ошибках номер 1603, 214 728 7035, 2203 и 1723.
Обязательно убедитесь в наличии доступа системы к каталогам временных файлов. Откройте «Свойства системы» (Win+Pause или в контекстном меню по правому клику мышкой на иконке Мой компьютер выберите строку Свойства), в «Дополнительных параметрах системы»,
на вкладке «Дополнительно» щелкните по кнопке «Переменные среды».
Находим папки временных переменных (они в своих названиях имеют слова TEMP, TMP), проверим, есть ли к ним доступ у системы (по уже описанному выше алгоритму). Надеюсь, вы помните, чтобы узнать адрес такой папки, необходимо сделать двойной клик по переменной
и, скопировав указанный путь, вставить содержимое буфера обмена в строку проводника и сделать переход к папке. А заодно можете сделать и полезное дело – очистить все временные папки от их содержимого.
Также будет верным решением проверить на наличие прав доступа те директории, в которые планируется инсталлировать приложения и каталог с именем Config.Msi в корне системного раздела. Для всех обозначенных выше каталогов должно быть отключено шифрование, т. к. Windows Installer в таком случае не имеет к ним доступа, в отличие от пользователя.
Ну, и естественно, ошибка установки может происходить по причине нарушенного установочного файла (т. н. «битый» файл, с несовпадением контрольных сумм), в такой ситуации необходимо разжиться заведомо «рабочим» нормальным установочным файлом. Скорее всего, будет иметь смысл скачать его из другого источника или по другому зеркалу.
Экспорт реестра
Вы также можете найти в сети копию раздела чужого реестра и импортировать ее на свой компьютер. Необходимая вам директория называется «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver».
Сброс параметров виндовс инсталлер
Если вы удалили вирус, отключили защитное ПО на время установки программы – фактически, исключили все возможные причины неисправности, но все по-прежнему, обратитесь к специалистам или же вернитесь к шагу установки ОС заново.
Теперь вы знаете что ошибки Виндовс инсталлера легко решаются и подключить обратно службу проще простого. Есть вопросы? С радостью ответим!
Можно ли удалить каталог, если папка Installer в Windows занимает много места?
Как уже было сказано, данный каталог является защищенным, и просто так удалить его не получится (система не даст этого сделать). Некоторые «спецы» разрешают данную проблему по-своему, используя для разблокирования утилиту Unlocker. Что ж, это их дело. Но вот когда папка Windows Installer удалена, у них почему-то отказываются работать некоторые программы. В частности, это касается самого обычного офисного пакета. Для вызова отдельно взятых приложений, входящих в его состав, становится невозможно использовать ярлыки, не удается произвести установку дополнительных компонентов приложений и т.д. Впрочем, это касается и всей операционной системы, поскольку проблемы могут наблюдаться и с ней. Удалять объекты по одному в самом каталоге, надеясь на русское авось, тоже нельзя. Последствия будут теми же.
Какой методике отдать предпочтение?
Остается выбрать оптимальное решение по поводу выполняемых действий. Как, по всей видимости, уже многие догадались, каталог лучше всего переместить в другое место или воспользоваться безопасной очисткой с помощью специализированной программы для удаления патчей. А вот производить ручное удаление и папки, и ее содержимого не рекомендуется ни под каким надуманным предлогом, поскольку потом никакое восстановление системы не поможет, не говоря уже о том, что многие приложения станут абсолютно неработоспособными, равно как и установка апдейтов или дополнений операционной системы и нужных пользователю программ.
Очистка папки Windows от мусора
Далее мы посмотрим, почему папка Windows занимает 45 ГБ, что очень странно. Открыв более подробное описание, мы с вами видим, что 70% папки Windows на моем хосте RDS фермы, занимают три папки:
- Installer
- ServiceProfiles — в данной папке хранятся кэшированные шрифты для различных программ, для каждого пользователя
- WinSxS — Это служебная папка операционной системы Windows служащая для хранения ранее установленных версий системных компонентов. Благодаря ее наличию существует возможность отката к более старой версии обновления в случае необходимости
Что такое и как очистить папку ServiceProfiles
ServiceProfiles — в данной папке хранятся кэшированные шрифты для различных программ, для каждого пользователя. Когда таких пользователей много, то и размер папки может быть большим. Как видите по пути C:\Windows\ServiceProfiles\LocalService\AppData\Local, лежит огромное количества FontCache файлов, по 8 МБ. Как я и говорил выше, это кэшированные шрифты, под каждую программу для каждого пользователя. В моем случае, данная папка занимает 10 ГБ, что очень много.
Я нашел ответ от разработчика Windows, что делал эту службу кэширования, его зовутNiklas Borson, вот что он отвечал, на вопрос, почему на RDS ферме, папка ServiceProfiles имеет большой размер.
Эти файлы FontCache-S — * .dat создаются службой Windows Font Cache. Я разработчик этой службы и могу подтвердить, что сказал Крис выше. Можно безопасно удалять эти файлы. Служба просто обновит их по мере необходимости. Просто чтобы подтвердить, проблему, которую вы наблюдаете, — с большим количеством файлов. Другими словами, упомянутый выше размер, должен быть общим размером для всех файлов. В Windows 8 и 8.1 каждый файл должен быть 8 МБ.
Как вы уже догадались, эти файлы предназначены для каждого пользователя, поэтому, если многие пользователи заходят на сервер, вы можете получить множество из этих файлов. К сожалению, служба Font Cache автоматически не удаляет старые файлы кэша для каждого пользователя, поэтому я боюсь, что вам придется обойти это самостоятельно. Например, вы можете создать запланированную задачу обслуживания, которая автоматически удалит все файлы FontCache-S — * .dat, если их общий размер превышает определенную сумму. Это безопасное обходное решение.
Кэширование происходит, чтобы разгрузить центральный процессор от постоянного обращения, тем самым сэкономив производительность.
В свою очередь, вы можете сделать bat файл вот с таким содержимым, и удалять файлы старше 30 дней из папки ServiceProfiles. Скрипт останавливает две службы:
- Служба кэша шрифтов Windows (Windows Font Cache Service)
- Кэш шрифтов Windows Presentation Foundation 3.0.0.0 (Windows Presentation Foundation Font Cache 3.0.0.0
net stop FontCache && net stop FontCache3.0.0.0
forfiles /P C:\Windows\ServiceProfiles\LocalService\AppData\Local /M FontCache* /D -30 /C «cmd /c del @path»
net start FontCache && net start FontCache3.0.0.0
Процедура очистки с использованием стороннего приложения
Специалисты из Microsoft, по понятным причинам, не приветствуют удаление содержимого из системных директорий Windows.
Однако, огромные размеры каталога «Инсталлер» вынудили других специалистов разработать приложение, которое позволяет безопасно для системы произвести очистку папки.
Программа носит название «PatchCleaner» и установить ее можно прямо с официального источника ее разработчика.
Приложение может выявить файлы, которые допустимо стереть из памяти без негативных последствий для нормальной работоспособности системы, а также показывает, какие файлы потребуются для ОС в дальнейшем и не позволит их удалить, так как это может привести к возникновению ошибок.
Процедура установки приложения полностью стандартная.
Завершив инсталляцию, потребуется перезапустить ПК и затем запустить утилиту. В автоматическом режиме она осуществит анализ файлов в каталоге «Инсталлер» и покажет пользователю количество нужных файлов и тех, которые допускается удалить.
Если понадобится более детальная информация, то достаточно клацнуть «details» и ознакомиться с подробным отчетом.
Для опытных пользователей предусмотрена возможность более тонкой настройки работы фильтров. С этой целью достаточно кликнуть рисунок «Шестерни» в меню утилиты и далее, например, настроить приложение на сохранение файлов, относящихся к определенным компонентам и ПО.
Сам процесс очистки сводится всего к нескольким следующим действиям:
Если пользователь не имеет возможности либо желания устанавливать дополнительное приложение, то можно просто перенести папку в другой том жесткого диска и тем самым освободить место на системном разделе.
Читайте также: