如何找到已安装 MSI 文件的升级代码? [英] How can I find the Upgrade Code for an installed MSI file?

问题描述

在某些情况下需要检索已部署包的 MSI 升级代码.

常见场景:

• 我接手了别人的 MSI 项目，我需要确定哪些升级代码用于已经存在的先前版本.这是处理升级方案所必需的.我在任何地方都没有发布存档.
• 在开发过程中，我不小心更改了我的 WiX 包的升级代码几次，我需要在野外"找到所有升级代码版本.我不知道升级代码应该在版本之间保持稳定.

<小时>

这是一个问答式问题.

这个问题以前曾以各种形式出现过，但这不是重复的.我发布了一种使用主 MSI 自动化界面(或严格来说是 WMI)的方法.它应该比之前答案中基于注册表的方法更可靠.这个答案还试图总结其他检索方法.

解决方案

MSI 升级代码检索(通过 PowerShell/WMI)

<块引用>

正在卸载?:

这些是直接来自相关机器上的Windows Installer 数据库的真实的实时值.不需要任何转换或解释.我们正在使用适当的 API.

技术说明！:请注意，直接在原始 MSI 文件(属性表)或 WiX 源文件中检查属性可能与实际安装的值不匹配，因为属性可以在安装时通过

上述查询中指定的产品代码用于Windows SDK Intellidocs".您显然必须将其替换为您自己的产品代码 guid.要查找您需要传入的产品代码，您还可以使用此处所述的 PowerShell 查询:

---

手动检索升级代码

本节列出了一些手动方式"；检索不需要任何编码或命令行的升级代码.这些手动方法不是推荐的方法.我包括它们只是因为这试图成为参考答案".应该提供几个不同的选项.我的建议是使用上面提供的 PowerShell 或 VBScript.

话虽如此，升级代码通常不应跨产品版本更改，因此您可以尝试在 MSI 文件本身或用于编译它的源代码中找到的代码，如下所述.已经多次提到的问题是转换可以在安装时更改升级代码，因此如果您想确保找到正确的升级代码，则需要以编程方式检索升级代码.除非您尝试从系统上未安装的 MSI 获取升级代码.然后您只需要一个 MSI 文件查看器，如下面的第 1 点所述.

转换只是一个数据库片段，其中包含在安装时应用于原始 MSI 的更改.它是一种主要用于企业应用打包的工具，无需直接修改MSI文件即可修改安装程序.转换具有扩展名 .mst.通过转换更改升级代码是不寻常的，但并非闻所未闻 - 特别是对于企业重新打包.在极少数情况下，应用程序打包者可能会有意更改升级 guid，以使他们能够为已安装的软件包提供自己的升级(而不是直接依赖供应商更新).很少见，但我已经看到它完成了.这是否是一件好事，值得商榷.

轻松、手动方式查找 MSI 升级代码:

1. 虽然很明显，但找到升级代码的最简单方法是打开用于安装产品的原始 MSI 并在属性表中找到升级代码强>.您所需要的只是一个能够打开 MSI 文件的工具.这里有一些工具:什么安装产品使用?InstallShield、WiX、Wise、高级安装程序等.如果你安装了 Visual Studio，你最快的选择可能是 Orca(搜索 Orca-x86_en-us.msi 并安装它 - 这是微软自己的官方 MSI 查看器和编辑器)，或者 Super Orca，如果你安装了没有安装 Visual Studio(按照上面的链接找到它).

2. 如果您是使用 WiX(或任何其他部署工具)的开发人员，您显然可以在用于编译 MSI(或Installshield 源、Advanced Installer 源或您正在使用的任何部署工具).

   • 我们不要在这里提出太多善意的建议，以免混淆主要问题，但您显然应该在源代码中硬编码升级代码，并且永远不要自动生成它！
   • 升级代码定义了相关产品系列"；并且应该跨版本(版本)保持稳定.在大多数情况下，它也应该跨语言版本保持稳定.确切的设置取决于部署要求.
   • 如果产品应该能够并排存在，您通常会为需要共存的产品使用不同的升级代码.
   • 经验法则:尽可能长时间保持升级代码稳定.当需求绝对需要时更改它们.
   • 总结:永远不要对有自己生命周期"的不同产品使用相同的升级代码；并且彼此之间没有真正的关系.他们没有关系.这与保持相关产品的升级代码稳定一样重要.思考生命周期"；和家庭关系"；和共存"；要求.
   • 这是一个很大的题外话，回到手头的问题:查找升级代码.

3. 即使您没有原始 MSI，甚至可以在 %SystemRoot%Installer缓存的 MSI> 文件夹.这里的 MSI 文件有一个神秘的十六进制名称，但它们只是用于安装不同产品的原始 MSI 文件的副本 - 缓存在安全的地方，可用于修改、修复和卸载操作.无论你做什么，都不要在这个文件夹里乱搞.永远，永远不要删除任何东西.您可以通过选择第一个 MSI 文件并检查 Windows 资源管理器状态栏来找到安装产品的 MSI，旧 Windows 版本的产品名称是什么.在 Windows 10 中，您似乎可以使用指针将鼠标悬停在 MSI 上，然后您会看到一个包含一些 MSI 详细信息的弹出窗口.然后您只需点击列表，直到找到合适的产品并打开 MSI 并在属性表中找到升级代码.

4. 有些人使用注册表来读取升级代码:How can I find the upgrade code for an installed application in C#?.In my opinion this is not a good approach, there are better ways - such as just using PowerShell as explained above.There is no need for all this conversion and interpretation of packed GUIDs (which is the GUID format used in the Windows Installer registry database).

That should complete the primary "manual methods" to retrieve an upgrade code quickly. Just some methods for the arsenal that are sometimes good enough. There are probably several more ways that I have forgotten.

Do prefer the programmatic approaches, but if you are in a rush and working without all your tools available some manual options are good. However some of these manual methods require more tools than the PowerShell command line (you need an MSI file viewer which is not always available on the box if you are on a "support mission" to someone's machine). The time has come to use PowerShell (yes, I feel outdated too).

Incidentally, MSI files are essentially stripped down SQL Server databases stored as COM-structured storage files (MS Office file format). Essentially a file system within a file with storage streams of various types.

If you are stuck on a machine without an MSI viewer, you can query cached MSI databases directly from PowerShell:

• https://gallery.technet.microsoft.com/scriptcenter/Get-MsiDatabaseProperties-09d9c87c
• http://www.adamtheautomator.com/powershell-windows-installer-msi-properties/

In certain cases the need to retrieve MSI upgrade codes for deployed packages can arise.

Common scenarios:

• I took over someone else's MSI project, and I need to determine what upgrade codes were used for previous versions that are already in the wild. This is necessary to handle upgrade scenarios. I have no archive of releases anywhere.
• I accidentally changed the upgrade code for my WiX package several times during development and I need to find all Upgrade Code versions "in the wild". I was not aware that Upgrade Codes should remain stable between versions.

---

This is a Q/A style question.

This question has come up before in various incarnations, but this is not a duplicate. I am posting a way to do it that uses the main MSI automation interface (or strictly speaking WMI). It should be more reliable than registry based approaches from previous answers. This answers also tries to summarize other retrieval approaches.

解决方案

MSI Upgrade Code Retrieval (via PowerShell / WMI)

Uninstalling?: Via Upgrade Code, Via Product Code, Via Product Name, etc...

The PowerShell script below should retrieve all related product codes, upgrade codes and product names installed on your machine (table output).

Screenshot of output (full script below):

These are the real, live values directly from the Windows Installer database on the machine in question. There is no need for any conversion or interpretation. We are going through the proper APIs.

Technical note!: Be aware that checking properties directly in your original MSI file (property table) or WiX source file, may not match actual installed values since properties can be overridden at install time via transforms (more info below) - or property values specified at the command line. The moral of the story: retrieve property values directly from the system when you can.

Quick disclaimer: In rare cases running the script can trigger a Windows Installer self-repair. Read more in "disclaimer section" below. Just a potential nuisance, but read the disclaimer please.

As a digression, there is also a one-line PowerShell command which will retrieve product codes and upgrade codes only - without the package name included. This might actually suffice for some users (I would recommend the full script below however). There is a screenshot of the output of this one-liner in a section below. Note: this command appears a lot faster than the larger script (the "Value" field is the upgrade code). Also note: product codes without associated upgrade codes will not show up as far as I can tell - they will in the larger script:

gwmi -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'" | Format-Table ProductCode,Value

To run the full PowerShell script below:

1. Launch PowerShell (hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK or hit enter).
2. Copy the script below in its entirety, and then just right click inside the PowerShell window.
3. This should start the script, and it will take quite a while to run.
4. Please report any problems. I am no PowerShell expert - I am a deployment specialist not a coder, but the script should do the job.
5. Performance note: I just get the whole Win32_Product WMI object
   • Cherry picking properties seemed to actually make it marginally slower (VBScript test).
   • I guess we need to get all rows anyway, and cherry picking columns is just extra lifting?
   • For Win32_Property we filter both rows and columns (upgrade code is just one of many row-types). Be prepared for a slow operation, WMI is very slow.

$wmipackages = Get-WmiObject -Class win32_product
$wmiproperties = gwmi -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'"
$packageinfo = New-Object System.Data.Datatable
[void]$packageinfo.Columns.Add("Name")
[void]$packageinfo.Columns.Add("ProductCode")
[void]$packageinfo.Columns.Add("UpgradeCode")

foreach ($package in $wmipackages) 
{
    $foundupgradecode = $false # Assume no upgrade code is found

    foreach ($property in $wmiproperties) {

        if ($package.IdentifyingNumber -eq $property.ProductCode) {
           [void]$packageinfo.Rows.Add($package.Name,$package.IdentifyingNumber, $property.Value)
           $foundupgradecode = $true
           break
        }
    }
    
    if(-Not ($foundupgradecode)) { 
         # No upgrade code found, add product code to list
         [void]$packageinfo.Rows.Add($package.Name,$package.IdentifyingNumber, "") 
    }
}

$packageinfo | Sort-Object -Property Name | Format-table ProductCode, UpgradeCode, Name

# Enable the following line to export to CSV (good for annotation). Set full path in quotes
# $packageinfo | Export-Csv "[YourFullWriteablePath]MsiInfo.csv"

# copy this line as well

Running on Remote Machines

• It should be relatively easy to extend the script above to run on remote machines, but I am not set up to test it properly at the moment.
• The information below has gotten a bit messy, let me know if it is not understandable or unclear.
• In a real Windows domain it should (in theory) just be a matter of adding the remote machines to the WMI calls themselves (and loop over a list of machines - see mock-up below). And crucially: you should use a real domain admin account to run the query. It is possible that the changes I list below to make WMI work in workgroup environments also could be required for some domains, I don't know (firewall rule and UAC registry tweak). I would guess that a real domain admin account should have the privileges and access required though.
• Remote connections in WMI are affected by (at least) the Windows Firewall, DCOM settings, CIMOM Settings and User Account Control (UAC) (plus any additional non-Microsoft factors - for instance real firewalls, third party software firewalls, security software of various kinds, etc...). Here are some details:
  • Setting up a Remote WMI Connection
  • Connecting to WMI Remotely with PowerShell
• In non-domain networks (small office, home, etc...) you probably have to add user credentials directly to the WMI calls to make it work. And you probably must have "real admin rights" on the machines in question to make the queries run remotely in a home network (workgroup). I have heard that the built-in Administrator account does not have any UAC issues, but I have never tried it. In my opinion: don't use this account.
  • In my testing I had to (1) update the Windows firewall rules and (2) disable the Remote UAC access token filtering and use a real, local admin account on the remote system. Note that I don't recommend either of these changes, just reporting what worked for me.
  • Change 1: Windows Firewall, run command (cmd.exe, run as admin): netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes (source - see this link for command line to disable this new rule again if you are just testing. Essentially just set enable=no). See the linked source for potentially more restrictive rules that could also work.
  • Change 2: Disable Remote UAC access token filtering: you need to set the following registry value: HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem LocalAccountTokenFilterPolicy = 1 (source - mid page, latter half). I set a 32-bit DWORD.

With those changes in place on the remote system, I also added user credentials to each call by prompting the user $Cred = Get-Credential. There are also more advanced options for defining the user credentials, as explained here: Pass password into -credential (and here). To test run, here is a little test script. Copy all lines below, modify the remote machine name and paste into PowerShell by right clicking (you will be prompted for credentials):

$Cred = Get-Credential
gwmi -ComputerName RemoteMachineName -credential $Cred -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'" | Format-Table ProductCode,Value
# copy this line too

For the large PowerShell script above, the basic additions for remote running on several machines in a Windows domain, could be something like this (I won't update the above script since I can't really test this properly). Remember to update the list of remote computer names at the top of the script and run with a domain admin account:

# DOMAIN NETWORK: mock-up / pseudo snippet ONLY - lacks testing, provided "as is"
$ArrComputers = "Computer1", "Computer2", "Computer3"
foreach ($Computer in $ArrComputers) 
{
    # here we modify the WMI calls to add machine name
    $wmipackages = Get-WmiObject -Class win32_product -ComputerName $Computer
    $wmiproperties = gwmi  -ComputerName $Computer -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'"

    # the rest of the above, large script here (minus the first 2 WMI lines)
}

To adapt the same machine loop for a non-domain network you can add credentials to the WMI calls. Something like this (you will be prompted for credentials for each machine - which might be confusing). Remember to update the list of remote computer names at the top of the script and use an account with local admin rights on the target box:

# WORKGROUP NETWORK: mock-up / pseudo snippet ONLY - lacks testing, provided "as is"
$ArrComputers = "Computer1", "Computer2", "Computer3"
foreach ($Computer in $ArrComputers) 
{
     $Cred = Get-Credential

     # here we modify the WMI calls to add machine name AND credentials
     $wmipackages = Get-WmiObject -Class win32_product -ComputerName $Computer -credential $cred
     $wmiproperties = gwmi  -ComputerName $Computer -credential $cred -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'"

     # the rest of the above, large script here (minus the first 2 WMI lines) 
}

The real answer ends here. I believe the above newer script should cover most use-cases, but I will leave the content below as well since it is not obsolete, just probably less efficient than the above script. Reading it will probably be repetitious.

The scripts below for retrieval of single upgrade codes rather than the whole list, could be of interest if you want to retrieve a single upgrade code from within your own application at run-time. I'll leave that older content in.

Disclaimer: The above script uses WMI, and when you access the class Win32_Product it triggers an integrity check of installed packages. This is quite slow, and can in very special cases trigger an MSI self-repair. This is not good if you are heading into an important meeting :-). Luckily you should be able to cancel any triggered self-repairs (but your query will probably not complete until you let the repair finish). Quick context link (for safekeeping).

IMHO: don't let this stop you from using WMI - it is just an annoyance. Note: both the PowerShell and VBScript approaches described below use WMI and can trigger this issue as well.

---

Retrieving Upgrade Codes For MSI Files That Are Not Installed

If you need the upgrade code for an MSI package that is not installed on your machine, please read the "Manual Retrieval of Upgrade Codes" section towards the bottom for several options (essentially look in the MSI file itself, or its source file used to compile it).

It is not safe to get the upgrade code for installed packages from the original MSI install file itself or from the (WiX) sources used to compile the MSI, because upgrade codes can be overridden at install time using transforms (details in text below - transforms are little database fragments applied at install time, see that Symantec link for details).

The programmatic retrieval of upgrade codes relies on WMI, and you can use either PowerShell or VBScript to invoke WMI. Both methods are presented below. Essentially the following WMI query is run to retrieve the upgrade code for a specified product code:

SELECT * FROM Win32_Property WHERE Property='UpgradeCode' AND ProductCode='{YourProdGuid}'

It is the same query used for both VBScript and PowerShell. You can also run it as a straight WMI query using a tool such as as WMIExplorer.exe. A very useful tool - highly recommended. I believe this is their site: https://github.com/vinaypamnani/wmie2/releases

---

Retrieve Single Upgrade Code Via PowerShell / WMI

Rather than outputting a whole table with all product codes and upgrade codes, you can retrieve a single upgrade code for a specified product code. This is good if you are trying to do the retrieval from inside your own application code (then it is just a standard WMI query and has nothing to do with PowerShell).

Below is the single upgrade code retrieval done via PowerShell (to launch PowerShell: hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK or hit enter):

gwmi -Query "SELECT Value FROM Win32_Property WHERE Property='UpgradeCode' AND ProductCode='{YourGuid}'" | Format-Table Value

The output should be something like this (maybe a little hard to read, I should have used larger fonts):

The product code specified in the query above is for "Windows SDK Intellidocs". You must obviously replace it with your own product code guid. To find the product code you need to pass in, you can also use a PowerShell query as described here: How can I find the product GUID of an installed MSI setup?

The returned upgrade code is coming straight from the real Windows Installer registry database. It requires no further processing or interpretation or manual conversion steps. It will also be correct, even if a transform changed the original upgrade code when the MSI was installed (details on transform issues below).

Update, special notice: Without complicating things unnecessarily, I believe I have found a bug in WMI that is very specific. When an original MSI has no upgrade code set, and you add one via a transform, then WMI does not seem to report the upgrade code at all. However: if the original MSI has an upgrade code, and you override it in a transform, WMI reports the transform's upgrade code (which is expected). I definitely saw this, but will need to verify with one more test package to be sure. The moral of the story: always set an upgrade code in your MSI! Then you avoid the whole issue permanently. And don't auto-generate it - hard code it (read "Manual Retrieval of Upgrade Codes" below for an explanation).

---

Retrieve Single upgrade code using VBScript / WMI (Legacy Approach)

There is nothing wrong with the VBScript solution found below - it even has some benefits over PowerShell - despite VBScript being a legacy technology by now. The benefits are that it should work on all machines, even when the .NET framework is missing (or locked), and on machines where PowerShell is missing (or locked). It is a dated, but viable solution that is quite flexible (unless VBScript is also locked, but all modern OS versions fully support VBScript).

In order to make it as simple as possible to retrieve your upgrade code, I have created a "bare-bone VBScript" which should do the trick. It has not been tested for targeting remote computers, even if WMI should be able to do so by design. The script is intended to be run on the system where your mystery MSI with the unknown upgrade code is installed.

This VBScript requires an input product code (input dialog shown when script is run), and it will then proceed to look up the corresponding upgrade code (if any). As stated above, to locate the product code for your MSI, you can use this approach: How can I find the product GUID of an installed MSI setup?. Once you have the product code (guid), you can run this VBScript on the target machine and you should get the upgrade code returned to you in a few seconds. WMI retrieval can be very slow.

'
' Purpose: Barebone / minimal VBScript implementation to allow retrieval of MSI UpgradeCodes via WMI.
'
' Version: 0.2, September.2017 - Stein Åsmul.
'
' Notes:
'
'  - As it stands, this script is intended to be run interactively (WScript).
'  - Conversion to run via CScript should be trivial (nothing ever is...)
'  - The script will ask the user to provide a valid product GUID for an installed MSI.
'  - To find a valid product GUID for your system, perhaps see this SO answer: https://stackoverflow.com/a/29937569/129130
'  - The script does not RegEx anything to check for valid GUID format (this is barebone - as terse as possible,
'    with as little as possible included that can break).
'
' UPDATE: for information on remote running, check "Running on remote machines" section here:
' https://stackoverflow.com/a/46637095/129130 (firewall and registry change seems to be needed).

strComputer = "."
' Remote connections was NOT tested for this script. In principle you should just add the machine name to "strComputer" above.
' AFAIK you must have "real" admin rights on the box you try to connect to. Many users report intermittent problems running remote WMI.
' Remote connections in WMI are affected by the Windows Firewall, DCOM settings, and User Account Control (UAC).
'    - Setting up a Remote WMI Connection: https://msdn.microsoft.com/en-us/library/aa822854(v=vs.85).aspx
'    - Connecting to WMI on a Remote Computer: https://msdn.microsoft.com/en-us/library/aa389290(v=vs.85).aspx
'    - Perhaps useful: https://social.technet.microsoft.com/Forums/lync/en-US/05205b52-0e43-4ce3-a8b8-58ec4c2edea5/wmi-generic-failure-when-accessing-win32product-remotely?forum=winserverManagement
'    - Maybe it is also worth noting that I think WMI queries can be slow enough to trigger timeouts,
'      and then you have the old favorite: intermittent bugs.

Set owmi = GetObject("winmgmts:{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")

' User interaction
productcode = InputBox("Please paste or type in the product code for the product whose upgrade code you want " + _
                       "to retrieve (not case sensitive, a blank product code will abort the script)." + vbNewLine + vbNewLine + _
                       "Please note that the script can take up to a minute to run due to WMI's slowness.", "UpgradeCode retrieval:")
If productcode = vbCancel Or Trim(productcode) = "" Then
   WScript.Quit(0)
End If

' Run WMI call and verify that it completes successfully.
On Error Resume Next
Set upgradecode = owmi.ExecQuery("SELECT Value FROM Win32_Property WHERE Property='UpgradeCode' AND ProductCode='" & productcode & "'")
If (Err.number <> 0) Then
   MsgBox "The WMI query failed, this is a critical error - aborting.", vbCritical, "Fatal error."
   WScript.Quit(2) ' Following exit code "standard" from MSI SDK automation samples
End If
On Error GoTo 0

' Report results.
Select Case upgradecode.count

   Case 0
       ' We have to provide a separate message for this state, since some packages may not have an UpgradeCode.
       ' However, the product GUID could also have been misspelled.
       MsgBox "No UpgradeCode was found, are you sure you entered the correct product GUID?" & vbNewLine & vbNewLine & _
              "Note: It is possible for a product to NOT have an UpgradeCode.", vbInformation, "No UpgradeCode found."

   Case 1
      ' The "default state" - should cover almost all normal packages.

      ' Only one upgrade code should have been retrieved, and it can be referenced by upgradecode.ItemIndex(0).Value on newer systems 
      ' (Vista and later), but on XP this apparently does not work (never tested by me), for compatibility we use a standard For Each 
      ' enumeration instead. Source: https://stackoverflow.com/questions/2378723/get-first-record-from-wmi-execquery

      For Each u in upgradecode
        Msgbox "The Upgrade Code is: " & u.Value & vbNewLine & vbNewLine & _
              "Just press CTRL + C to copy all text in this dialog (then paste to notepad or similar to extract the GUID).", _
              vbInformation, "UpgradeCode found."
          ' Exit For
      Next

   Case Else
       ' Should never get here - let us know if you do get this message.
       MsgBox "An error occurred, the query returned more than one result. There can only be one UpgradeCode. " & _ 
              "Please report this error on StackOverflow", vbInformation, "Error while retrieving UpgradeCode."
End Select

Retrieving All Upgrade Codes and Product Code on a Machine

I should mention that I have a large VBScript which will generate a comprehensive HTML report for all installed MSI packages on the machine it runs on. This includes all upgrade code and a list of related product codes (product codes that share the same upgrade code). However, I am not too happy with the code (I am a deployment specialist, not a coder). The script is too large, too slow and too untested for use, so I create the bare-bone VBScript found above to do retrieval for a single package only. This script is much easier to test and modify for your own use. I can provide this large VBScript for testing if of interest. It is read-only apart from a single HTML file output to "My Documents". It should be possible to adapt this script for use on remote computers as well.

There is a one-line PowerShell command to retrieve all product codes and related upgrade codes, but this output fill lack the name of the products. I include it here for completeness:

gwmi -Query "SELECT ProductCode,Value FROM Win32_Property WHERE Property='UpgradeCode'" | Format-Table ProductCode,Value

The output will be similar to this (the "Value" field is the upgrade code - product codes without associated upgrade codes will not show up as far as I can tell):

---

Manual Retrieval of Upgrade Codes

This section list some "manual ways" to retrieve upgrade codes that don't need any coding or command lines. These manual approaches are not the recommended ones. I include them only because this attempts to be a "reference answer". Several different options should be provided. My recommendation is to use the PowerShell or VBScript provided above.

That being said, upgrade codes should generally never change across versions of your product, so chances are you can try the one you find in the MSI file itself, or in the source used to compile it as described below. The problem that has already been mentioned several times is that a transform can change upgrade codes at install time, so you need to retrieve the upgrade code programatically if you want to be sure you find the correct one. Unless you are trying to get the upgrade code from an MSI that is not installed on your system. Then you just need a MSI file viewer as described below in bullet point 1.

A transform is just a database fragment with changes that are applied to the original MSI at install time. It is a tool mostly used for corporate application packaging to modify installers without modifying MSI files directly. Transforms have the extension .mst. Changing the upgrade code via a transform is unusual, but not unheard of - especially for corporate repackaging. In rare cases application packagers may intentionally change the upgrade guid to enable them to deliver their own upgrades to the packages installed (instead of relying on the vendor updates directly). Rare, but I have seen it done. Whether this is a good thing or not is highly debatable.

Easy, manual ways to find MSI upgrade codes:

1. Though offensively obvious, the easiest way to find the upgrade code is to open the original MSI used to install the product and find the upgrade code in the Property table. All you need is a tool capable of opening MSI files. Here are some tools: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc. Your fastest bet is probably Orca if you have Visual Studio installed (search for Orca-x86_en-us.msi and install it - this is Microsoft's own, official MSI viewer and editor), or Super Orca if you don't have Visual Studio installed (follow the above link to find it).

2. If you are a developer using WiX (or any other deployment tool), you can obviously find the upgrade code easily in your WiX source file that you used to compile your MSI (or Installshield source, Advanced Installer source, or whatever deployment tool you are using).

   • Let's not fly off the handle here with too much well meant advice that clutters the main issue, but you should obviously hard code the upgrade code in your source, and never auto-generate it!
   • Upgrade codes define "families of related products" and should remain stable across releases (versions). In most cases it should remain stable across language versions as well. The exact setup depends on deployment requirements.
   • If products should be able to exist side-by-side you typically have different upgrade codes for the products that need to co-exist.
   • Rule of thumb: keep upgrade codes stable for as long as possible, whenever possible. Change them when requirements absolutely demand it.
   • To wrap things up: never use the same upgrade code for different products that have their own "life cycle" and no real relation to each other. They are not related. This is just as important as keeping your upgrade code stable for related products. Think "life cycle" and "family relation" and "co-existence" requirements.
   • That was a large digression, back to the issue at hand: finding upgrade codes.

3. Even if you don't have the original MSI, it is even possible to locate the cached MSI from the original install in the %SystemRoot%Installer folder. The MSI files here have a mysterious hex-name, but they are just copies of the original MSI files used to install the different products - cached in a safe place to be available for modify, repair and uninstall operations. Whatever you do, don't mess around in this folder. Never, ever delete anything. You can find the MSI that installed your product by selecting the first MSI file, and checking the Windows Explorer status bar what the product name is for older Windows version. In Windows 10 it seems you can hover over an MSI with the pointer and you get a pop-up with some MSI details. You then just click through the list until you find the right product and open the MSI and find the upgrade code in the Property table.

4. Some people use the registry to read the upgrade codes: How can I find the upgrade code for an installed application in C#?. In my opinion this is not a good approach, there are better ways - such as just using PowerShell as explained above. There is no need for all this conversion and interpretation of packed GUIDs (which is the GUID format used in the Windows Installer registry database).

That should complete the primary "manual methods" to retrieve an upgrade code quickly. Just some methods for the arsenal that are sometimes good enough. There are probably several more ways that I have forgotten.

Do prefer the programmatic approaches, but if you are in a rush and working without all your tools available some manual options are good. However some of these manual methods require more tools than the PowerShell command line (you need an MSI file viewer which is not always available on the box if you are on a "support mission" to someone's machine). The time has come to use PowerShell (yes, I feel outdated too).

Incidentally, MSI files are essentially stripped down SQL Server databases stored as COM-structured storage files (MS Office file format). Essentially a file system within a file with storage streams of various types.

If you are stuck on a machine without an MSI viewer, you can query cached MSI databases directly from PowerShell:

• https://gallery.technet.microsoft.com/scriptcenter/Get-MsiDatabaseProperties-09d9c87c
• http://www.adamtheautomator.com/powershell-windows-installer-msi-properties/

这篇关于如何找到已安装 MSI 文件的升级代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！