Установщик Windows запрещает определенные места установки - PullRequest
0 голосов
/ 25 мая 2018

Иметь файл MSI, который запускается пользователем вручную.Они должны иметь возможность выбирать каталог установки в большинстве случаев, однако нам нужно запретить определенные места установки.Например, установка его в корневой каталог C:\ вызовет всевозможные проблемы, поэтому нам нужно либо перезаписать это решение (то есть перезаписать C:\ с помощью C:\Program Files (x86)\xxx), либо всплыть с ошибкой.Есть ли какой-нибудь способ, которым я могу применить это?

В MSI, о которой идет речь, уже есть пользовательские действия, однако, похоже, нет способа отредактировать место установки оттуда.

В качестве альтернативыВ этом случае msi обернут в пакет WiX, поэтому, если мы можем запретить определенные каталоги, это также будет хорошо.Хотя и не могу найти способ сделать это (знаю только, как редактировать значение по умолчанию с помощью <Variable Name="InstallFolder" ...>)

Только другое решение, которое я могу придумать, будет довольно ужасным: создайте отдельное приложение, которое выбирает каталог, который затемзапускает установщик с допустимым каталогом.

Можно ли это сделать с помощью msi или пакета WiX?

Я использую расширение "Visual Studio 2013 Installer Projects" для создания msi.

Ответы [ 3 ]

0 голосов
/ 25 мая 2018

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

  1. В InstallUISequence упорядочить действие LaunchCondition доперед действием ExecuteAction.

  2. Затем в таблицу LaunchCondition добавьте условие, например, так:

    Условие: TARGETDIR ~ << "C:\ Program Files \ "</p>

    Описание: Вы должны установить в папку Program Files

Что мы говорим в условии:

Если TARGETDIR начинается с «C: \ Program Files \» (следовательно, пользователь может установить в любом месте в этой папке), продолжите установку.В противном случае выведите ошибку.

Вместо того, чтобы предотвращать определенные местоположения, я бы, вероятно, просто применил папку Program Files в качестве лучшей практики.

0 голосов
/ 25 мая 2018

Как противоположное мнение:

В общем, это плохая идея.В большинстве случаев правильным ответом будет установка кода приложения в соответствующую папку Program Files (64-разрядная или x86), а файлы данных - в местоположения данных и т. Д., И у пользователя не должно быть выбора.Мне не ясно, что выбор является хорошей идеей, когда (например) правила сертификации Windows говорят, что ваш код должен идти в папку Program Files, поэтому просто сделайте это правильно.Пользователи просто заботятся о том, чтобы установленное приложение работало правильно, и если оно не работает при установке в некоторых местах, то ответом является либо: 1) исправить приложение, чтобы оно работало, либо 2) использовать программные файлы и не дать пользователю выбора.

Кроме того, если вы используете проекты установщика Visual Studio, вы не можете написать собственные действия для этого, потому что все они выполняются слишком поздно, чтобы изменить место установки.Вы, кажется, уже обнаружили это.Но вы МОЖЕТЕ скрыть диалоговое окно просмотра папок и установить в правильное местоположение по умолчанию.

Другая проблема заключается в том, что неясно, как вы определяете «разрешенное» местоположение.Если это не C: \, то может ли это быть D: \ SomeOtherLocation?Это может быть подключенный USB-накопитель?Это может быть сетевой ресурс, такой как \\ Servername \ share?Подключенный диск к сетевому ресурсу?Вероятно, будет любое количество выбранных местоположений, которые не смогут установить приложение или приложение при его запуске, и я не думаю, что может быть полезный список того, что разрешено.Кроме того, предположим, что у вас установлена ​​32-разрядная версия, и пользователь выбирает собственную папку Program Files в 64-разрядной системе, тогда она даже не будет туда идти - она ​​будет перенаправлена ​​в Program Files (x86)место нахождения.Наконец, неясно, что вы делаете в режиме автоматической установки, если предположить, что пользователь указывает местоположение в командной строке, он не проходит ваш тест, а затем установка завершается неудачно (так как «без вывода сообщений» означает «без вывода сообщений», и установка может быть выполнена без присмотра).

Другими словами, просто установите в Program Files и покончите с этим.

0 голосов
/ 25 мая 2018

Пользовательское действие : это будет коротким.Перепроверяю позже.Я не могу сказать, что пытался реализовать это недавно, но пользовательское действие, безусловно, может проверить место установки и прервать установку или остановить ее - если выбранный путь окажется неудовлетворительным.Также следует отметить, что MSI активно сопротивляется установке непосредственно в корень C:\ и тому подобному из-за способа реализации таблицы Directory.

GUI : Я полагаю, что одним из способов было бы запустить настраиваемое действие, когда пользователь нажимает кнопку Next в диалоговом окне настройки пути назначения установки, которая затем выполняет «все, что вы хотите» с точки зрения проверки пути, а затем сообщает о любых ошибках.Это включает DoAction event, подключенную к кнопке OK или Next в диалоговом окне настройки пути.

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

Github : у меня нет кода WiX, чтобы вы могли реализовать его на этом компьютере.Я бы нажал github.com и поискал другие проекты, использующие WiX - вы, вероятно, найдете что-то быстро - без денег и WiX бесплатно.

...