Показать полную графическую версию : [архив] Inno Setup .:[все вопросы]:.
Сложилось впечатление, что гуру этого топика мне не поверили.
В аттаче тестовая программка, где прописано удаление файла в полном соответствии с документацией на Inno Setup Compiler 5.2.2.
В таком виде функция не работает. Помогите разобраться: где тут моя ошибка, или это баг ISC, о чём стОит запросить авторов?
ChVL, а если так
[Files]
Source: {app}\Test.txt; DestDir: {app}; Flags: deleteafterinstall
unikum111
04-03-2008, 04:28
Каким образом можно вернуть прежние ассоциации файлов после деинсталляции программы?
snark,
Эта функция работает, пользовался ею. В данном случае она не устраивает: файл надо удалить после того, как он сделает своё дело - будет запущен или открыт.
Так что, потревожить авторов Inno?
jameszero
04-03-2008, 12:27
ChVL
А если так:
[Files]
Source: {app}\Test.txt; DestDir: {app}; Flags: deleteafterinstall
[Run]
Filename: "{app}\Test.txt"; Flags: shellexec
Если не подходит, опишите конкретную задачу, что и в какой момент времени нужно запустить, а потом удалить.
jameszero,
Всё работает как надо.
Очевидно, что флаг deleteafterinstall срабатывает тогда, когда пройден весь скрипт, в том числе и секция [Run]. На такой алгоритм мне и следовало обратить внимание. Спасибо за науку.
И всё-таки секция [InstallDelete] команды не выполняет - явный баг, IMHO.
snark,
Вероятно Вы имели ввиду это же решение. Прошу прощения, что не понял сразу.
jameszero
05-03-2008, 16:06
ChVL
[InstallDelete] отрабатывает до установки. По крайней мере, так сказано в справке.
... entries are processed as the first step of installation.
jameszero,
Дык, не отрабатывает ни - до, ни - после! - Файл не удаляется.
jameszero
05-03-2008, 18:13
ChVL
На примере скрипта из 181 поста:
Предварительно создаём папку Profram Files\Test, кладём в неё файл Test2.txt и компилируем скрипт
[Setup]
AppName=Test
AppVerName=Test
DefaultDirName={pf}\Test
OutputBaseFilename=Test
DefaultGroupName=Test
Compression=lzma
[Files]
Source: "{app}\Test.txt"; DestDir: "{app}";
[InstallDelete]
Type: files; Name: "{app}\Test2.txt";
Инсталлируем программу - файл Test2.txt удалён, Test.txt "установлен".
Из [InstallDelete] неполучится удалить файл Test.txt потому, что эта секция срабатывает до секции [Files] (если быть точнее, файл удаляется и сразу создаётся опять).
jameszero,
То, что и как Вы раскопали, - просто класс!
Реально имеет право на существование и такой вариант: файлы имеют одинаковое название, а содержание - разное. Это может быть полезно в том случае, когда делается инсталляция программы более поздней версии поверх предыдущей, и при этом необходимо какой-то файл(ы) заменить новой версией.
ChVL, файлы имеют одинаковое название, а содержание - разное. Это может быть полезно в том случае, когда делается инсталляция программы более поздней версии поверх предыдущей, и при этом необходимо какой-то файл(ы) заменить новой версией. »
вот в мануале условия замены существующих файлов
Remarks
If a file already exists on the user's system, it by default will be replaced according to the following rules:
If the existing file is an older version than the file being installed (as determined by the files' version info), the existing file will be replaced.
If the existing file is the same version as the file being installed, the existing file will not be replaced, except if the replacesameversion flag is used and the content of the two files differs.
If the existing file is a newer version than the file being installed, or if the existing file has version info but the file being installed does not, the existing file will not be replaced.
If the existing file does not have version info, it will be replaced.
то есть вкратце, существующий файл заменяется новым, если:
1. он старше по дате (определяется по дате в свойствах файла);
2. указан флаг replacesameversion в свойствах нового файла или содержание файлов различно;
3. у существующего файла нет версии (version info).
jameszero
06-03-2008, 15:35
snark
Всё верно, для замещения старого файла новым, шаманств с [InstallDelete] не потребуется, но допустим такая ситуациия:
Программа при первом запуске создаёт свои конфигурационные файлы и с ними работает, а в следующей версии автор решает изменить формат (имена) этих файлов. Вот тут и пригодится [InstallDelete]
jameszero, да, такой вариант я что-то не продумал... Подходит идеально.
И хотя ChVL имел в виду именно одинаковое имя и разное содержание, бывают же случаи, когда все наоборот
скажите можно ли извлеч файлы из setup-1.bin,setup-2.bin,... если фаил setup.exe потерян?
при запуске innounp.exe выдает сообщение о повреждениях и несовместимостях
unpacker последней версии
Как сделать, чтобы любым unpacker'ом нельзя было добраться до скрипта? Устроит любой вариант, к примеру:
- скрипт не извлекается (как будто его и нет);
- извлекается, но не читается;
- извлекается, но запаролен.
Как сделать, чтобы любым unpacker'ом нельзя было добраться до скрипта? »
Запаролить дистрибутив, но кому надо, тот распакует. :)
Но опять же, не все так просто. ;)
boss911,
Это я уже пробовал. Не подходит. Речь идёт о скрипте. Дистрибутив должен использоваться как обычно, т.е. пользователь сборки может и не догадываться о существовании скрипта в принципе.
Как сделать, чтобы любым unpacker'ом нельзя было добраться до скрипта? »
Могу посоветовать поподробнее изучить секцию code по идее её средствами можно сделать все что угодно ... но это не самый простой путь.
Второе перейти на другой инсталлятор в котором невозможно получить скрипт установки в том виде в каком он был до компиляции дистриба (например Nsis)
Ну и третье а что у тебя действительно такой серьезный проект что его надо так защищать ?
Ведь если у тебя используются только те функции что предоставляет innosetup (без серьезного использования секции code и внешних библиотек), то твой инсталлятор скорей всего очень легко будет сделать самостоятельно просто отслеживая изменения файловой системы и реестра. Ну еще может пару библиотек зарегистрировать придется.
ZaV,
секцию code по идее её средствами можно сделать все что угодно
IMHO, с помощью секции [Code] можно творить чудеса в пределах компилятора, но она, в моём представлении, бессильна вне скрипта, что по определению требуется для решения поставленной задачи. Или я не прав?
перейти на другой инсталлятор
Это понятно, только вот нет желания...
действительно такой серьезный проект
Да нет, не так уж серьёзно. Понадобилось скрыть регистрационные данные. В реестре это явным образом не засвечено, а вот в скрипте легко можно засечь. Есть и другой прецедент. Сознаю, что для грамотного программера любые ухищрения с защитой – семечки, но никто из них копаться не станет. Хотелось бы защититься от массы любителей запускать unpacker.
WindoStroy
15-03-2008, 23:15
ChVL,
вот может поможет:
Простенький способ криптования инсталлятора c использованием подсчета хеша MD5 "обманных" символов. (Пароль будет находиться в памяти). Требуется ISCrypt.dll в одной папке с Inno Setup
[Setup]
AppName=Pass
AppVerName=Pass
DefaultDirName={pf}\Pass
Uninstallable=No
Encryption=Yes
;MD5 сумма, подсчитанная ниже
Password=449f2546d2a51b20442c5025c43f126f
[Files]
Source: "C:\1.txt"; DestDir: "{app}"
[Code]
procedure InitializeWizard();
var
MD5: String;
begin
//Подсчитываем сумму слагаемых в MD5 калькуляторе, на примере сумма MD5 "````" равна 449f2546d2a51b20442c5025c43f126f
MD5 := GetMD5OfString(''+'`'+'``'+'`')
WizardForm.PasswordEdit.Visible:= False;
//Вставляем то, что складываем
WizardForm.PasswordEdit.Text:= MD5;
end;
//Как обычно нажимаем страницу с пассом
procedure CurPageChanged(CurPageID: Integer);
begin
if CurPageID = wpPassword then
WizardForm.NextButton.OnClick(WizardForm.NextButton);
end;
(с) Kindly
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.