Пользовательское действие не работает во время удаления

Я разрабатываю установщик с помощью Installshield 2011, а тип проекта — Basic MSI, у меня есть настраиваемое действие, которое упорядочено таким образом, что его следует выполнять во время удаления. вот прикрепленный снимок свойств пользовательских действий, которые я настроил.

Снимок прикрепленного настраиваемого действия для удаления

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

Ниже приведена запись из подробного журнала:

00532: (Unknown): InstallShield 11:01:17: Registering Msi Server...

00533: (Unknown): InstallShield 11:01:17: **Invoking script function MyFunction**

00534: (Unknown): InstallShield 11:01:17: **CallScriptFunctionFromMsiCA() ends**

00535: (Unknown): CustomAction NewCustomAction1 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

00536: (Unknown): Action ended 11:01:17: **NewCustomAction1. Return value 3.**

00537: (Unknown): Action ended 11:01:17: **INSTALL. Return value 3.**

00538: (Property): Property(S): DiskPrompt = [1]

00539: (Property): Property(S): UpgradeCode = {40AD9645-1459-4C32-8285-D1C0B163361D}

00540: (Property): Property(S): ProductCode = {84BDE810-2C23-48CA-A638-5B131DA3B57F}

Я что-то пропустил здесь?


person Chetan    schedule 01.04.2013    source источник
comment
Что пытается выполнить ваше пользовательское действие? Пытается ли он взаимодействовать с файлами, которые (уже) были удалены в процессе удаления? В качестве примечания: я избегаю InstallScript как чумы.   -  person NGaida    schedule 01.04.2013
comment
Приветствую, NGaida, текущее пользовательское действие содержит только всплывающее сообщение, кроме этого я ничего не делаю. По сути, я хотел протестировать его, прежде чем я смогу выполнить свою фактическую реализацию, которая заключается в удалении тега XML из файла app.config во время удаления.   -  person Chetan    schedule 01.04.2013
comment
InstallScript надежен, начиная с InstallShield 12. Тем не менее, я больше не инвестирую в него. Обычно я делаю все на C#/DTF и иногда на C++. Но я не избегаю InstallScript, скажем так.   -  person Christopher Painter    schedule 01.04.2013
comment
@ChristopherPainter Мне нужно удалить 2 приложения во время установки моего msi-файла. Я написал программный код для удаления приложения и вызвал эту функцию в installer.cs. Но это не удаление приложения, я поднял вопрос в ТАК, пожалуйста, изучите это и помогите мне stackoverflow.com/ вопросы/26863294/   -  person user2725407    schedule 11.11.2014


Ответы (1)


Мой первый вопрос: почему вы вообще пишете пользовательское действие? Встроенные настраиваемые действия InstallShield ( XML File Changes ) уже имеют возможность удалить элемент при удалении. Мое второе наблюдение заключается в том, что язык InstallScript надежен, это отсутствие понимания того, как правильно разрабатывать пользовательские действия, которые обычно вызывают проблемы. Я боюсь:

Этапы установки и параметры выполнения в скрипте для настраиваемых действий в установщике Windows

Не забудьте запланировать все настраиваемые действия, изменяющие систему, как отложенные в контексте системы между InstallInitialize и InstallFinalize. Также обязательно используйте шаблон CustomActionData и предусмотрите соответствующие действия по откату на случай отмены или сбоя удаления. В противном случае вы можете столкнуться с ситуацией, когда ваше приложение установлено, но тег отсутствует.

И, конечно же, никогда не изобретайте велосипед там, где он уже существует. (XMLFileChanges) Это редко бывает хорошо.

person Christopher Painter    schedule 01.04.2013
comment
Я был обожжен InstallScript еще с ISWI, когда он только вышел. С тех пор я избегал этого и просто использовал пользовательские действия C++. Хотя я полностью согласен; не изобретать велосипед. Если вы чувствуете, что вам это нужно, вы должны спросить себя, почему. - person NGaida; 01.04.2013
comment
Согласованный. В то время у вас должен был быть setup.exe, который запускал среду выполнения движка, и у вас были всевозможные проблемы с DCOM/ROT, которые приводили к ошибкам. Это также нарушило принципы MSI, разрешив отложенным пользовательским действиям доступ к дескриптору MSI. Однако все это было исправлено 7 лет назад: blog.iswix.com /2006/04/installshield-12-beta2.html - person Christopher Painter; 01.04.2013
comment
Спасибо, ребята, я пойду с XMLFileChanges - person Chetan; 02.04.2013