Переместите приложение из «Program Files x86» в «Program Files» при обновлении до 64-разрядной версии. - PullRequest
1 голос
/ 24 мая 2019

Приложение изначально было доставлено в 32-битной форме. Теперь он распространяется с 32- и 64-битной версией.

Теперь, когда пользователь в 64-битной Windows обновляет приложение с 32-битной версии до 64-битной версии, папка установки по умолчанию должна указывать на «Program files» (без x86).

Я обновил мои wsx файлы таким образом:

    <?if $(var.Platform) = x64 ?>
        <?define bitness = "(64 bit)" ?>
        <?define Win64 = "yes" ?>
        <?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
    <?else ?>
        <?define bitness = "(32 bit)" ?>
        <?define Win64 = "no" ?>
        <?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
    <?endif ?>
      ....
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="$(var.PlatformProgramFilesFolder)">
                <Directory Name="COMPANY" Id="D.COMPANY">
                    <Directory Name="Product name" Id="APPDIR">

                    </Directory>
                </Directory>
            </Directory>
        </Directory>

И это прекрасно работает для новых установок:
Когда 32-битное приложение установлено в 64-битной системе, оно устанавливается в «Program files x86», а во всех остальных случаях установка выполняется в «Program files».

В случае обновления с 32-х до 64-битных папкой назначения по умолчанию по-прежнему остается «Program files x86», и мне нравится, если она перемещается в «Program Files».

Есть ли хороший способ сделать это? Или мне нужно переопределить это какое-то настраиваемое действие в моем коде C ++?

Редактировать / Update
Просто быть чистым. Мое приложение является фоновым сервисом. Пользователь машины вообще не видит это приложение (за исключением крайних угловых случаев). В большинстве случаев эта служба устанавливается / не обновляется другой службой, которая может в удаленном режиме и удаленно устанавливать необходимое программное обеспечение.

Во время этого обновления все 32-битные компоненты очищаются (один exe и пара dll-ов) и заменяются 64-битными эквивалентами. Данные конфигурации и кэшированные данные передаются в обновленное приложение.

RemoveExistingProducts установлено на <RemoveExistingProducts After="InstallInitialize" />

Ответы [ 2 ]

2 голосов
/ 24 мая 2019

В целом : сначала пара вопросов:

  • Side-by-Side : Вы уверены, что не хотите поддерживать параллельную установку 32- и 64-разрядных версий? Different packages with different installation locations (and some shared components)?
    • Это иногда возможно - как переход на последнюю версию. Вы можете разрешить установку обеих версий одновременно на некоторое время (или навсегда).
    • Это зависит от того, сколько данных, установленных вашими пакетами, «запутано» (глобально зарегистрировано на машине и, следовательно, мешает между пакетами).
    • Вот ответ с разделом, посвященным смежным вопросам (внизу). Немного, но немного дискуссий по этому вопросу.
  • г. Hester : я бы прочитал этот устаревший, но хороший блог: Для разных архитектур процессоров требуются разные пакеты .

Практическая битность : Я ржавый, так что терпите меня, но я бы

  1. полностью установить новое место установки для вашего нового 64-битного пакета,
  2. желательно изменить название продукта,
  3. изменить все GUID компонентов (необходимо при перемещении места установки, объяснение здесь ) - использовать WiX auto-GUID , если возможно,
  4. помечает все компоненты, которые являются 64-разрядными, как 64-разрядные, а остальные - как 32-разрядные (очевидно: <Component Win64="yes" />),
  5. пометить пакет как 64-битный,
  6. изменить имя выходного файла, указав 64-битный пакет,
  7. Я мог бы установить новый код обновления для новой версии, но для этого требуется более сложная обработка таблицы обновления, чтобы упростить удаление 32-разрядной версии. Новый код обновления обычно необходим для поддержки параллельной установки. Есть много мелких деталей ... Например: WiX heat.exe не поддерживает извлечение 64-битных регистрационных данных COM .

Некоторые проблемы :

  • Есть ли у вас оставшиеся 32-битные компоненты? ( 64-битные пакеты ).
  • Глобальная область применения: есть ли какие-либо компоненты COM? Есть драйверы? Любые ассоциации файлов?
  • Предпосылки, которые имеют проблемы с битностью?

Ссылки

1 голос
/ 24 мая 2019

Здесь было обсуждение этого вопроса:

Обновление приложения и переключение с 64-разрядного на 32-разрядное

По сути, мой первый комментарий: если ваш a.NET-приложение, которое вы можете запустить 64-битным, даже если вы установили 32-битное.

Мой второй комментарий - я не верю (см. Комментарии в другой ветке). MSI поддерживает масштабное обновление и изменение битности.Это просто не тот случай использования, который был предусмотрен (например, x86 -> arm или x64 -> itanium).Я полагаю, что вам понадобится прожигатель записи, который обрабатывает удаление 32-битного MSI и установку 64-битного MSI как части пакета.

Что касается разработки MSI, ProgramFiles64Folder и ProgramFilesFolder - это разные каталоги и, следовательно, разные компоненты.ID GUIDS.

Еще одна вещь, которую следует учитывать, - это то, что для некоторых продуктов можно установить как 32-битную, так и 64-битную версию.В качестве примера можно привести переадресацию времени выполнения C ++.Может быть, было бы приемлемо спроектировать так, чтобы можно было устанавливать их бок о бок и просто положить на пользователя, чтобы удалить старый.

...