У меня есть ужасная проблема из моей попытки установки MSI:
MSI (c) (98:B0) [18:01:22:818]: Invoking remote custom action. DLL: C:\DOCUME~1\sspencer\LOCALS~1\Temp\1\MSI19.tmp, Entrypoint: CheckFX
MSI (c) (98:FC) [18:01:22:833]: Cloaking enabled.
MSI (c) (98:FC) [18:01:22:833]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (98:FC) [18:01:22:833]: Connected to service for CA interface.
Action ended 18:01:22: DIRCA_CheckFX. Return value 3.
После небольшого перекопа, это на самом деле указывает на то, что DLL не удалось загрузить напрямую, сервер CA не смог подключиться и начать попадание точек входа DLL.
Я использовал orca и 7zip для извлечения пользовательского действия для DIRCA_CheckFX, которое вставляется Visual Studio при создании проекта развертывания. Я схватил DLL, а затем выполнил Dependency Walker в хост-системе (Server 2003 R2), которая дала ошибку:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Я перекомпилировал систему с помощью компилятора VS 2010, извлек DLL и пропустил на ней хост зависимостей, который не создавал ту же ошибку. I.e VS 2010 компиляции работает, компиляция VS 2013 не выполняется, поскольку включенная DLL не будет загружаться в целевую среду.
Мой вопрос заключается в том, как устранить, какие DLL отсутствуют, чтобы устранить эту ошибку, сообщенную Dependency Walker.
Должен быть установлен VS 2010, из которого вы можете получить действительный файл "dpca.dll".
dpca.dll из
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Deployment до C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin.Предварительный просмотр .vdproj resurrection использует библиотеки DLL, которые не поддерживают Windows XP или Server 2003. Microsoft опубликовала обновление, которое могло быть исправлено эта ошибка.
Вот что я сделал, чтобы решить эту проблему для 32-разрядного проекта развертывания.
Создайте проект установки в VS2010 один раз. Этот пакет не устоял в этом вопросе, но я не хотел, чтобы он продолжал строить в другой версии VS.
Откройте полученный msi с помощью Orca, выберите двоичную таблицу и экспортируйте содержимое MSVBDPCADLL в файл.
Теперь, после сборки в VS2013, используйте Orca для импорта экспортированных данных в Binary\MSVBDPCADLL для исправления пакета.
Мне нужно сделать аналогичную вещь с 64-битным проектом, но в этом случае он импортирует правильный бинарный файл InstallUtil (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtilLib.dll).
Проекты развертывания Visual Studio были настолько ужасны, что Microsoft удалила их из Visual Studio 2012. Разработчики были настолько невежественны в отношении того, почему они были ужасны, что они умоляли и умоляли их вернуться. Разумные ребята из Microsoft, которые понимают MSI, покинули здание, а люди остались в покое, чтобы разработчики просили его вернуться.
Один из тех действительно умных парней прекрасно подытожил его в чириканье:
Возврат vdproj: Headshots, люди, или они возвращаются в качестве ходунков.
Я написал статью о своих чувствах: Воскрешение установщика Visual Studio
Итак, расскажите о том, как на этот раз инструмент вас не сбит. Потратьте минутку, чтобы прочитать эту статью, написанную одним из других действительно умных, чтобы оставить MSFT:
Zataoca: пользовательские действия (как правило) допуска к отказу.
VDRPOJ создал настраиваемое действие, чтобы сделать что-то, что MSI могла сделать изначально, и теперь он не работает. Итак, скажем, вы найдете DLL и исправьте ее для работы на вашем компьютере. Что произойдет, если вы отправляете MSI на 1 000 000 машин? Сколько машин оно выйдет из строя? Сколько вызовов поддержки вы получите? Сколько твитов вы получите, что ваш продукт отстой?
Проще говоря, я бы переделал ваш установщик с помощью лучшего инструмента, такого как XML-установщик Windows и Industrial Strength Windows Installer XML. Если у вас есть деньги на то, чтобы потратить InstallShield Professional, это тоже хороший выбор.