» VMware ThinApp (formerly Thinstall) 3

pavlaf
У нас уже было, когда мы фичу долго считали багом:
http://forum.ru-board.com/topic.cgi?forum=5&topic=31117&start=1080#6

В данном же случае ощущение, будто разработчики... не сразу решили, баг это или фича

NickOnToluca
Я в теме по сравнению с вами новичок. Освоение программы начал с публикаций Astra55, vyachko и перелистывания страниц ветки обсуждения, но быстро понял, что это полезно, но не лучший вариант. Начинать нужно с оригинального мануала, поэтому и взялся за перевод.
Родной мануал оказался небрежно написанным и далеко не полным. Но так есть в мануале любой программы - обо всём не напишешь. Так что форум - великое подспорье. Только старые посты нужно читать осторожно. Последние версии программы заметно повзрослели, думаю, читать можно только то, что относится к актуальным 4.7.3 и 5.1.0.
Насколько я понял, других русских форумов по программе нет. Подскажите, если другие ресурсы всё же есть.

pavlaf
Есть, но, наверное, я сейчас и не вспомню.
Сам давно не вникал в нюансы, хотя немного портаблю для себя.

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

Это интересно и полезно:
http://www.vmgu.ru/search/ThinApp

Цитата:

Это интересно и полезно:
http://www.vmgu.ru/search/ThinApp

Действительно интересно! Кто просветит пошагово по поводу данного механизма???:


Цитата:

Возможность P2P (Project to Physical) - администратор может взять уже готовый пакет ThinApp и "распаковать" его в ОС таким образом, чтобы приложение оказалось установленным на целевой машине (уже не в контейнере, а нативно). Это можно использовать, например, для поиска проблем - распаковал пакет, а при сборе данных с этого нативного приложения секвенсором проанализировать логи и поведение приложения.

AVanti473
Там оговорка и поспешные выводы, должно быть не "готовый пакет ThinApp", а "готовый проект ThinApp". О новой функции преобразования проекта назад в нативно установленное приложение - раздел 6.5 руководства. Функцию распаковки пакета разрабы вряд ли добавят.
Но, имхо, практически сегодня можно выполнить преобразование ThinApp-пакета в нативно установленное приложение в два этапа:
- Пакет в проект (FAQ от Astra55).
- Проект в нативно установленное приложение (руководство).
Должно работать, только зачем это нужно?

pavlaf

Цитата:

Должно работать, только зачем это нужно?

Предварительные условия


Цитата:

6.5
...
Перед извлечением существующего ThinApp-проекта в систему захвата и сборки убедитесь, что соблюдены следующие условия:
...
- Профиль пользователя в существующем виртуальном проекте такой же, как и в машине захвата и сборки.

Мда... Действительно - зачем?

И, кстати вполне понятно почему должны совпадать профили, иначе такие приложение как MS Word 2010 (и выше) просто не установятся на другой профиль, вот только тот же Total Uninstall с этой задачкой справляется в подобном случае намного проще.

1.Создаю ThinApp пекадж последней версии Google Chrome, но при запуске получаемого exe-файла, обнаруживаю пропадание иконки Хрома, вместо иконки - пустая заглушка. Как это починить?

2. Хочу создать ThinApp пекадж Punto Switcher'а. Есть ли готовая инструкция или статья по виртуализации этого ПО? Планирую, что этим PS'ом будет пользоваться множество человек в компании и хочется, чтобы он автоматически загружался и у каждого пользователя был свой собственный словарь.

vashchukov


Цитата:

Создаю ThinApp пекадж последней версии Google Chrome, но при запуске получаемого exe-файла, обнаруживаю пропадание иконки Хрома, вместо иконки - пустая заглушка. Как это починить?

В Package.ini параметр InventoryIcon=


Цитата:

Есть ли готовая инструкция или статья по виртуализации этого ПО?

Не встречал готовых инструкций по виртуализации каких-либо конкретных программ.

Ребята как возможно с VMware ThinApp 5 создать Windows XP Sp3 Portable
Пример если работаю в Win 7/8 и надо Windows XP Sp3 просто открыл внутри Win 7/8 и все,
а не через VirtualBox 4.3 / VMware Workstation 10
Спосибо .

jiko
Никак. Не для этого он

Просьба помочь.
Есть портабельная сборка, к ней подключаются плагины *dat, некоторые из них при этом не запускаются, но если их dll вынести в реальную систему все работает.
При сборке таких плагинов с параметром "ChildProcessEnvironmentDefault=External" и "ExternalDLLs=нужные dll" в песочницу также ничего не выносится. Что делаю неверно?
Или данный параметр применим только к основному хосту и с плагинами не работает?
(У плагинов ведь своей песочницы нет, как я понимаю, или она общая?)

oplrox, в *.dat находятся exe-шники для запуска? Проверял через файлменеджер(RollerNT) запускать "хуковые" проги(экранную клавиатуру, скриншотер ScreenHunter 6) - действует, но их dll-ки не появляются. При этом только песочница хоста используется.
Часом не мультимедиа в плагинах? такое вообще привередливое... Например, VST-эффекты часто приводят к вылету аудиоредактора.

SunOK_ZM
У меня несколько VST работают и не жужжат.
Но в целом да, некоторые капризничают.

oplrox
Можно еще раз? В какой конфигурации работает, а в какой нет?

oplrox

Цитата:

но если их dll вынести в реальную систему все работает.  

Цитата:

При сборке таких плагинов с параметром ... "ExternalDLLs=нужные dll" в песочницу также ничего не выносится.

Сталкивался с таким. Некоторые dll-ки, будучи заданными в ExternalDLLs=, все равно не выносятся в песочницу. В этом случае их надо выносить скриптом.

NickOnToluca, coherent, SunOK_ZM, спасибо что отозвались. Опишу ситуацию подробнее.

В *dat запортабелен VST плагин, как обычно в его папке dll, в профиле библиотеки пресетов и записи в реестре. Если собрать этот dat без dll, а последние закинуть в реальную систему то все работает как надо (с регистрацией и подгрузкой пресетов). А вот если библиотеки оставить внутри контейнера (т.е. сделать все как обычно), зависает при запуске.
Похоже, плаг хочет работать с процессами в системе, и по идее, с выносом его библиотек в песочницу должно работать, но как я писал выше ChildProcessEnvironmentDefault=External эффекта не дал.
Читал у Astra55 что можно в портейбл поместить файлы с нулевым размером, а в песочницу подставить реальные, но пока что не проверял, да и каждый раз подставлять вручную файлы тоже не очень.

coherent, если нет других то это вариант, у вас случаем нет примера такого скрипта?

На всякий случай, версия ThinApp 4.7.0

oplrox
А что именно за плагин?

NickOnToluca, это любой из плагов Acon Digital и Sonoris (есть на рутрекере). С Sylenth1 такая же ситуация, думал тоже про скрипты, но к сожалению не силен в этой области...

Вобщем с помощью скрипта удалось вынести dll в песочницу, теперь уже пишет ошибку при загрузке плагина: "fatal error plugin editor" как-то так... Перепробовал десятки вариантов, с разными плагинами, в том числе и с файлом нулевого размера в разных комбинациях... Возможно, тут дело в изоляции, ведь песочница для сборки - среда с заданными параметрами, получается, что даже вынося файл в песочницу, доступ к нему все равно происходит через параметры виртуальной среды...

Можно еще все настройки и файлы(кроме dll) оставить в сборке, а последние подгружать в систему. Это уже конечно не портейбл, но все равно мусора будет меньше, да и другой выход что-то не просвечивается...

Кстати забыл сказать, NickOnToluca, вам спасибо за видео-мануал по AppLinks, полезный материал...

oplrox
Сталкивался также с тем, что иногда недостаточно вынести dll-ку только в песочницу, нужно также выносить ее рядом с исполняемым ехе-файлом сборки. dll-ку из сборки в песочницу нужно перемещать, типа fso.MoveFile. При этом dll-ка, если мне не изменяет память, все равно должна быть задана в ExternalDLLs=. Не факт, что в вашем случае сработает, но попробовать можно.

Цитата:

Можно еще все настройки и файлы(кроме dll) оставить в сборке, а последние подгружать в систему. Это уже конечно не портейбл

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

Цитата:

Сталкивался также с тем, что иногда недостаточно вынести dll-ку только в песочницу, нужно также выносить ее рядом с исполняемым ехе-файлом сборки.

Аналогично! Например программа TeraCopy - dll-ки, при выносе, тоже не работают без екзешника.

coherent, нашел ваш скрипт, файл все равно не появляется возле exe, и после выхода запускается бесконечный цикл старта программы.

Есть некоторый прогресс.

Кстати, метод fso.MoveFile при старте выдает ошибку, возможно я где-то допускаю ошибку в синтаксисе. Пошел другим способом: поместил dll в другую папку, методом fso.CopyFile скопировал в реальную систему, так работает. Но перед этим, в параметрах сборки с этого пути была снята изоляция, иначе файл копируется в песочницу, а оттуда он не работает.
Но теперь вопрос по скрипту, каким методом удалить папку при завершении работы программы?
Вобщем, без знания оккультных путей VBS никуда.


AVanti473, по поводу решения с TeraCopy, если сохранился скрипт по выносу dll, скиньте пожалуйста...

oplrox
1. А если просто нужные длл-ки положить рядом с ехе сборки, выкинув их из проекта? Даже просто руками.
2.
Цитата:

поместил dll в другую папку, методом fso.CopyFile скопировал в реальную систему, так работает. Но перед этим, в параметрах сборки с этого пути была снята изоляция, иначе файл копируется в песочницу, а оттуда он не работает.

Для копирования в реальную систему лучше использовать xcopy.
3. Судя по вашим вопросам, вам стоит просмотреть мануал в той части, которая относится к использованию скриптов.
4.
Цитата:

каким методом удалить папку при завершении работы программы?

Ответ на вопрос - например, fso.DeleteFolder. Все зависит от конкретной задачи. И если вы хотите получить конкретную помощь, то и задачу надо обрисовывать не в общем, а более конкретно: что, откуда и куда надо вынести, удалить и т.д...

Цитата:

...то и задачу надо обрисовывать не в общем, а более конкретно...

Портабельный хост Reaper, подключаемый плагин VST в виде *dat, в сборке это: "%ProgramFilesDir%\VstPlugins\Acon Digital\Verberate\Verberate.dll"
Имеющееся решение:
- при сборке проекта задаются параметры ChildProcessEnvironmentDefault=External и ExternalDLLs=Verberate.dll
- Verberate.dll перемещается в %AppData%
- снимается изоляция с %ProgramFilesDir%\Acon Digital\Verberate\
- добавляется скрипт, который копирует при запуске хоста файл Verberate.dll в реальную систему по указанному пути и при завершении работы хоста его удаляет (вернее должен удалять папку).
Код: Const OverwriteExisting = True
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.CopyFile ExpandPath("%AppData%\Verberate.dll"), ExpandPath("%ProgramFilesDir%\VstPlugins\Acon Digital\Verberate\"), OverwriteExisting
Function OnLastProcessExit
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFolder ExpandPath("%ProgramFilesDir%\VstPlugins\Acon Digital")
End Function

oplrox

Цитата:

После закрытия хоста удаляется только файл Verberate.dll, а дирекории остаются на месте!

Сталкивался с таким, досконально причину не знаю, но думаю, что это связано с коллизией виртуальной и реальной папок Verberate при использовании метода .DeleteFolder.

Цитата:

Как это можно исправить, т.е.чтоб директория VstPlugins оставалась, а Acon Digital со всем что внутри удалялась?

Я бы пошел по такому пути:
- добавить в проект папку, которая не используется плагином, и куда закинуть Verberate.dll, предварительно удалив из %ProgramFilesDir%\VstPlugins\Acon Digital\Verberate, например %Drive_C%\VstPlugins\Acon Digital\Verberate\Verberate.dll.
- копировать папку VstPlugins со всем содержимым в реальную среду в %ProgramFilesDir% через cmd.ехе /C xcopy... в функции OnFirstSandboxOwner.
- удалять папку VstPlugins из реальной среды через cmd.ехе /C rd... в функции OnLastProcessExit.
В обоих случаях запускать через ExecuteExternalProcess.
Более подробно сейчас не могу расписать, загружен работой.

Добавлено:
Насчет папки VstPlugins в проекте в %Drive_C% я был не прав. Папка должна находиться вне проекта, рядом с dat-файлом плагина.

Цитата:

...добавить в проект папку, которая не используется плагином...

coherent, шикарно и просто, если освободить папку VstPlugins все работает, как сам не додумался)
CMD не стал задействовать (но взял на заметку), воспользовался тем же скриптом с изменениями.

Цитата:

Более подробно сейчас не могу расписать, загружен работой.

Да вам и так ОГРОМНЕЙШАЯ БЛАГОДАРНОСТЬ, сам бы копался невесть сколько, и не факт что докопался.

---

---

Итак, еще раз, описание задачи и решение, возможно кому-то пригодится:
Портабельный хост Reaper, подключаемый плагин VST в виде *dat, в сборке это: "%ProgramFilesDir%\VstPlugins\Acon Digital\Verberate\Verberate.dll". Плагин при портировке стандартным способом не запускается, но работает при выносе в реальную систему.
Необходимо: при запуске хоста вынести в реальную систему папку с плагином, и после завершения работы хоста ее удалить.
Решение:
1. При сборке проекта в Package.ini задаются параметры ChildProcessEnvironmentDefault=External и ExternalDLLs=Verberate.dll
2. Папка с плагином Acon Digital перемещается в любую другую, к примеру в %AppData%, получается:%AppData%\Acon Digital\Verberate\Verberate.dll
3. Обязательно удаляется изоляция с папки %ProgramFilesDir%\VstPlugins, или выставляется в Merged.
Важно! ! Изоляция с вышеуказанной папки должна быть снята не только во всех подключенных плагинах, но также и в сборке хоста.
4. В корень проекта добавляется VBS-скрипт c содержанием:
Важно! ! При подключении нескольких плагинов, собранных таким способом, дабы избежать накладки записей, название скрипта должно иметь уникальное, не повторяющееся имя.
Код: Function OnFirstParentStart
Const OverwriteExisting = True
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.CopyFolder ExpandPath("%AppData%\Acon Digital"), ExpandPath("%ProgramFilesDir%\VstPlugins\"), OverwriteExisting
End Function
Function OnLastProcessExit
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFolder ExpandPath("%ProgramFilesDir%\VstPlugins\Acon Digital")
End Function

Цитата:

Важно! ! Название скрипта (в корне проекта) в каждой новой сборке должно отличаться от предшествующих, иначе не сработает.

Даже при условии очистки песочницы?

oplrox
Рекомендую закинуть первую часть скрипта в функцию OnFirstParentStart. Потому что так, как сейчас, objFSO.CopyFolder... срабатывает каждый раз при вызове любого родительского или дочернего процесса.

NickOnToluca
Речь по-видимому идет об одновременном подключении нескольких плагинов, собранных таким способом.

NickOnToluca

Цитата:

Даже при условии очистки песочницы?

Да, если таким способом собрано несколько *dat, и в каждом из них будет скрипт с одним названием, то при загрузке в созданной сборкой папке "ThinstallPlugins" окажется один скрипт, на который наложаться все записи, сборка это не поймет, в результате вообще ни один не сработает. Т.е. каждый скрипт в "ThinstallPlugins" должен иметь уникальное название.

coherent

Цитата:

Рекомендую закинуть первую часть скрипта в функцию OnFirstParentStart.

Пост с решением подредактировал.

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