Конфигурация: Windows Server 2008 x64.
Программное обеспечение кроссплатформенное c ++ 64bit.
Предыдущий установщик по умолчанию попросил пользователя установить на
c: \ Program Files (x86) \ company \ version
Для последнего выпуска я изменил установщик, используя переопределение пути для установки на
c: \ Program Files \ company \ version
Ребята, которые проводят тестирование для нас, сказали, что с новой установкой в c: \ Program Files \ sub процессы не запускаются. Переопределите установку в c: \ Program Files (x86) \ xxx все работает нормально. Переход к cmd.exe и запуск из C: \ Program Files \ xxx приводит к ошибке «yyy.exe не является приложением Win32». Опять же, это не проблема с c: \ Program Files (x86).
Клиент также установлен по умолчанию и получает те же ошибки.
Моя машина сборки / разработки не показывает ни одной из этих ошибок. Он работает с демо-версией сервера 2008 (и Visual Studio Express), который никогда не обновляется и никогда не перезагружается.
Есть ли что-то особенное в "x86", прикрепленном к программным файлам?
Примечание:
Это НЕ проблема на моем компьютере разработчика, который также является сервером 2008 x86_64.
dumbin / headers четко указывает, что эти программы 64-битные.
На данный момент нет ответа.
Обходной путь - просто установить в Program Files (x86) или в другом месте и покончить с этим. Помещает FAQ, который пользователи НЕ должны устанавливать в Program Files (они будут смотреть часто задаваемые вопросы, если что-то станет ядерным).
Это может быть проблема с установщиком, это может быть классический случай «quack.exe», но применительно к «Программным файлам». Есть веская причина, почему я вообще ненавижу окна.