Способы отладки установщиков NSIS?

Несмотря на то, что NSIS позволяет создавать довольно мощные инсталляторы, "такой язык низкого уровня, который напоминает мне об сборе", который использует NSIS, довольно подвержен ошибкам, и поэтому, когда вы хотите, чтобы ваш установщик делал что-то более сложное, кроме писать файлы, отладка обязательна.

До сих пор я использовал следующую технику отладки Dr Printf:

  • В файле .nsh, который я использую везде, я определяю макрос NSIS_DEBUG_MSG в соответствии со значением a DEBUG define
    • Если DEBUG включен, макрос будет вызывать MessageBox с отладочным сообщением
    • Если DEBUG выключено, макрос ничего не сделает

Этот метод послужил мне хорошо, но он имеет некоторые недостатки:

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

Так что я хотел знать, какие методы отладки вы используете для этих установщиков, так что, надеюсь, я смогу улучшить свою работу.

Ответ 1

Что сэкономило много времени, так это использование журналов, созданных NSIS. Оба журнала при компиляции скриптов и журнал установки. Они позволяют мне проверить, что макросы, которые я определил, используются, и что установка фактически запускает скрипты, они должны.

Это может показаться слишком маленьким, но на самом деле это все, что мне нужно, чтобы поддерживать мое установочное программное обеспечение из 50+ nsh файлов вместе с принципом "разделять принцип покорения".

Ответ 2

В течение моего времени, используя NSIS, это заметно:

Я выяснил, что ничего более мощного, чем синтаксический анализ! verbose 3-уровневый вывод с самодельным инструментом;)

Я выяснил, что вы не можете зависеть от метода отладки на основе NSIS. Это может привести к сбою.. и ваш установщик рухнет вместе с ним. Не красиво, а?: (

Я выяснил, что включение/отключение отладки по запросу также очень мощное оружие против idsses, поскольку оно позволяет различать нестабильную и неудачную сборку NSIS (проще использовать терминологию CI, хотя...:)).

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


Надеюсь, это поможет тем, кто случайно посещает этот вопрос:)

РЕДАКТИРОВАТЬ: Всегда полезно начинать с сторонних инструментов. Например, не нужно беспокоиться о графическом интерфейсе, так как всегда проще использовать такие инструменты, как:

  • EclipseNSIS (мне это не нравится: P)
  • Конструктор диалогов NSIS (http://nsis.sourceforge.net/NSIS_Dialog_Designer)
  • Самодельный статический анализатор кода. Я сделал один для себя: P

РЕДАКТИРОВАТЬ № 2: Я выяснил, что довольно эффективным методом для отладки является использование автоматической автоматизации документооборота. В настоящее время я использую следующие компоненты:

В результате я получил скриншот после nsDialog:Show плюс я получил обновленные изображения в wiki:).. осталось только получить информацию от svnlook:)


РЕДАКТИРОВАТЬ № 3: И необходимость в svnlook также обрабатывается путем создания библиотеки svn log -xml, экспортирующей DLL, с использованием заголовка NSIS v2.44 для Delphi и Lazarus IDE 0.9.30.2:) Престижность к Лазарю!

Woohoo!:)


РЕДАКТИРОВАТЬ № 4: Нажмите здесь небольшую дискуссию: http://forums.winamp.com/showthread.php?t=325521

Ответ 3

Вы можете загрузить одну из специальных сборок NSIS с официального сайта с расширенным протоколированием. Это даст вам очень подробную информацию о регистрации, облегчающую отладку.

Ответ 4

Я использую DumpState плагин, намного лучше, чем базовое сообщение для проблем с стеком. Я обычно использую макрос, который устанавливает все регистры; $0 = r0, $1 = r1 и т.д., Поэтому я знаю, что стек находится в правильном состоянии. Это, конечно, полезно только на этапе проектирования и не столько для отладки системы конечных пользователей...