Я ломал голову над этим и искал ответы в Google, но не нашел ничего интересного - я уверен, что это, вероятно, вопрос моих поисковых запросов на данный момент, но я надеюсь, что кто-то там знает, почему я я вижу это поведение.
Я хочу связать установку msi с соответствующим файлом \ Windows \ Installer \ msi_munged_file_name.msi. Я использую / l * vx logging, чтобы получить журнал установки MSI, и вижу такую запись:
PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\Windows\Installer\1f219540.msi'.
И я смотрю, как файловая система действительно создает этот файл. Но после завершения MSI файл переименовывается. о_О
Я прошел через 2 итерации этого, и оба раза файл был переименован в то, что было до +3 hex, я думаю. Итак, в этом случае я получаю файл с именем:
C:\Windows\Installer\1f219543.msi
Мне любопытно, почему происходит переименование, и если алгоритм действительно + 0x3 последний символ в имени файла, или если это просто совпадение на моих двух прогонах до сих пор.
Я использовал Orca.exe, чтобы убедиться, что файл, который приводит к C: \ Windows \ Installer, действительно является моим msi.
Это для исследования, которое я провожу по установщику Windows, и я пытаюсь лучше понять платформу установщика MSI / Windows.
Заранее спасибо!
Я нашел способ получить то, что мне нужно. Похоже, что во время установки установщик Windows выполняет «преобразование» кода продукта - я обнаружил, что это называется «упакованный GUID» - это странное (для меня) изменение кода GUID кода продукта. На это есть много ссылок.
Итак, я написал код, чтобы взять GUID кода продукта, «упаковать его», чтобы добраться до ключа:
@"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\" +
packedGuid +
@"\InstallProperties");
Затем вы можете прочитать значение LocalPackage и получить полный путь к локально кэшированному файлу MSI.
С помощью этого упражнения я многое узнал об установщике Windows.
Предполагая, что вы используете signtool, вы должны включить флаг опции /d MyProduct.msi