2012-02-20 5 views
3

Я использую WiX 3.6 для создания установщика.Запись места установки в реестр из установщика

Одна из потребностей заключается в том, чтобы указать местоположение места установки в реестр в HKCU или HKLM в зависимости от свойства ALLUSERS.

Теперь на основе исследования я сделал я думаю, что должно работать

<RegistryKey Root="HKMU" 
      Key="Software\OpenCover" 
      Action="createAndRemoveOnUninstall"> 
    <RegistryValue Name="Location" 
        Type="string" 
        Value="[APPLICATIONFOLDER]" 
        Action="write" 
        KeyPath="yes" /> 
</RegistryKey> 

Проблема заключается в том, что работает только когда ALLUSERS = «» т.е. HKMU интерпретируется как HKCU.

Если я попробую установку perMachine, где ALLUSERS = 1, запись не будет записана в HKLM, как ожидалось, хотя, когда я смотрю на файл журнала установщика, я вижу вызов WriteRegistryValues.

MSI (s) (D4:14) [22:46:24:901]: Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: [1], Name: [2], Value: [3]) 
Action 22:46:24: WriteRegistryValues. Writing system registry values 
MSI (s) (D4:14) [22:46:24:902]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=13200) 
MSI (s) (D4:14) [22:46:24:903]: Executing op: RegOpenKey(Root=-1,Key=Software\OpenCover,,BinaryType=0,,) 
MSI (s) (D4:14) [22:46:24:903]: Executing op: RegAddValue(Name=ConsoleLocation,Value=C:\Program Files (x86)\OpenCover\,) 
WriteRegistryValues: Key: \Software\OpenCover, Name: ConsoleLocation, Value: C:\Program Files (x86)\OpenCover\ 
MSI (s) (D4:14) [22:46:24:906]: Executing op: RegCreateKey() 
WriteRegistryValues: Key: \Software\OpenCover, Name: , Value: 

Может кто-нибудь объяснить, как достичь этой задачи мне нужно завершить

ответ

2

Проблема на самом деле связана с 32-разрядным установщиком на 64-битной платформе.

Когда в этом случае используется ALLUSERS = "1", записи реестра, помеченные HKMU, на самом деле записываются, но в этом случае HKLM \ Software \ Wow6432Node \ OpenCover. Я подозреваю, что записи, помеченные как HKLM, также перенаправлены таким же образом.

К сожалению, документация на WriteRegistryValues Action не объясняет перенаправление 32/64 «магического» перенаправления, а информация, касающаяся фактической записи реестра, не отображается в журналах.

Чтобы получить представление о том, что происходит, следующая статья демистифицирует наблюдаемое поведение Registry Keys Affected by WOW64. Из этой статьи мы видим, что установщик «думает» записывает в папку HKLM \ Software, но на самом деле это «перенаправлено» в HKLM \ Wow6432Node \ Software для 32-битного процесса на 64-битной платформе и, следовательно, объясняет почему он не отражен в файлах журнала. В статье также объясняется, почему, когда ALLUSERS = "", а HKMU - это HKCU, почему записи появляются там, где их можно было бы ожидать, потому что эти записи: "shared" между 32 и 64-битными приложениями.

+1

Это потому, что 32-битные процессы работают в виртуальной среде на 64-битной ОС: WOW64 (Windows на Windows). Не только перенаправляются ключи реестра, но и программные файлы и системный каталог: таким образом, 32-битный процесс на самом деле не знает, что он читает файлы из 'Program Files (x86)', он по-прежнему считает, что он работает с 'Program Files'. Установщик также подвергается этим перенаправлениям. Если вы устанавливаете 64-битный, используется 64-разрядный msiexec; в случае 32-битного пакета используется 32-разрядный msiexec. –

0

Я думаю, что установщик не подъемная (включен контроль учетных записей?) И что запись в HKLM перенаправляется HKCU.

Кстати, вы могли бы также рассмотреть возможность использования API-интерфейса установщика Windows из вашего приложения для запроса кода обновления, ProductCode, ProductInformation (INSTALLLOCATION) без необходимости писать раздел реестра для хранения этих метаданных.

+0

HKCU записывается только тогда, когда ALLUSERS = "" (как и ожидалось), когда ALLUSERS = "1", тогда я не вижу записи под HKLM или HKCU. Запись предназначена для использования сторонними системами сборки, такими как nant/msbuild, так что они могут запускать приложение во время процесса сборки, и у них уже есть утилита реестра, которая поможет в создании сценариев. –

+0

Я не думаю, что это UAC, поскольку код помещается в правильное место (Program Files), когда приложение ALLUSERS = «1». Я смущен, почему он не терпит неудачу, поскольку нет записей ... Я собираюсь использовать [монитор процесса] (http://technet.microsoft.com/en-us/sysinternals/bb896645) на нем и посмотреть, что происходит. Спасибо за ваши предложения –

+0

Можете ли вы опубликовать весь журнал? –

Смежные вопросы