如何比较两个（或多个）MSI文件的内容？ [英] How can I compare the content of two (or more) MSI files?

查看：140
本文介绍了如何比较两个（或多个）MSI文件的内容？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

如何对两个（或更多） MSI文件进行 内容比较，并查看文件中的实际区别-而不是执行无用的二进制比较？ （显然，这只会告诉我是否正在处理同一文件的副本。）



一些相关且典型的问题场景：




  • 我们的构建系统会疯狂地吐出MSI文件，有时我们需要弄清楚不同MSI文件之间存在什么区别（阅读：已更改） ，现在我们部署失败了。）

  • 我们从不同位置的相同源编译了MSI文件，其中一些文件无法运行报告 System.BadImageFormatException -我们如何调试MSI文件中的差异？ （在此处专门针对此错误的答案：应用程序是否依赖于编译环境？）。

  • MSI文件可以使用各种工具进行编译，但是对于stackoverflow用户而言，此类文件可能是最常创建的使用 WiX 或 Visual Studio安装程序项目 （免费工具包）。





这是 Q / A风格问题，以比较已编译的MSI文件以确定存在哪些真正的内容差异。

解决方案


Microsoft或ca ：如果已安装Visual Studio，请尝试搜索 Orca-x86_en-us.msi -在 程序文件（x86） -并安装它。然后在开始菜单中找到Orca。




  • 当前路径 ： C：\程序文件（x86）\Windows套件\10\bin\10.0.17763.0\x86

  • 适当更改版本号






< h2> 关于MSI文件

粗略地说， MSI 文件是 COM-结构化存储文件-本质上是文件内的文件系统-具有不同内容的流，其中一个是精简的 SQL Server数据库（我认为是最通用的术语）。如果MSI文件可读，则可以比较（各种格式和类型）的内容。



技术说明：可以想象，触发 System.BadImageFormatException 的MSI只是无法运行（ msiexec.exe 无法运行），但是它可能仍然可读-因此具有可比性（如果您遇到此问题，请添加评论以进行验证）。



流：某些 MSI中的流是具有字符串值的表。可能还存在用于嵌入式cab-archives 的流，这些流用于存储要部署的文件，以及仅具有 binary内容的表-例如 Binary表，其中已编译和未编译的自定义操作都与安装程序需要的其他二进制内容一起存储。并且有一个特殊的 摘要流和一个带有以其本机二进制格式存储的图标的表，该列表一直存在...对于大多数表，我们可以比较每个表中的字符串就像我们在Word文档中比较文本一样（也曾经是OLE / COM文件 -尽管新版本现在使用 Open Office XML ），并获得有关差异的详细报告。为此，您显然需要一种专用工具来完成这项工作-一种能够通过所有相关流找到其方式的工具。下面列出了一些用于此目的的商业和免费工具。



二进制内容：在详细说明之前，我应注意比较二进制表， Cabs表，图标表-或任何其他二进制表中，通常只允许您进行二进制比较（尤其是对于编译的自定义操作dll和exe文件）。可以将二进制表中的脚本自定义操作作为文本进行比较，但是编译后的自定义操作仅是二进制比较。因此，如果您的问题是由已编译的自定义操作引起的，那么您就无法在直接比较中真正看到它（您只能看到二进制差异）。 您需要访问源代码管理系统以查看用于任何类型的已编译自定义操作的代码-希望您具有良好的标签做法，以便您可以找到实际的源代码每个设置中使用的代码。我不使用这种做法，但是对于内部公司发行版，您甚至可以为已编译的自定义操作添加调试构建dll，并尝试将调试器附加到正在运行的代码中，以真正了解正在发生的情况？不过，我不会将调试模式的dll用于公开发行-除非我明确了所有风险。调试代码可能充满（意外的）调试消息框（用作附加调试器的入口点）和其他永远不会影响生产包的问题。



想到这一点，通过使用 dark.exe -如下所述。然后，使用一个好的比较工具（下面将提到超越比较），您可以对不同MSI版本之间的cab文件内容进行完全比较（某些文件可以是文本文件，可以进行文本比较）。我猜出租车和图标都是开放格式的透明二进制文件，而不是编译后的二进制文件（带有自定义操作等），而编译后的二进制文件本身并不是可反编译或检查的（除非您知道如何反编译托管二进制文件）。



结论： MSI文件是完全透明的，除了已编译的自定义操作 。 这种透明性是MSI的核心优势之一 。与以前的部署技术相比，大多数Windows Installer收益通常都围绕公司部署收益。不幸的是，开发人员可能只会看到MSI的不利方面： the （潜在）MSI反模式（朝下-暂时非常混乱和临时）。诚然，其中一些问题非常严重，违反了最小惊讶原则。开发人员-为什么要做其他同样重要的事情-可能会坦率地说，让人难以置信。



尽管如此，MSI具有巨大的企业部署优势（请参阅与上面相同的链接，朝底部）。 压缩：可靠的静默运行，远程管理，回滚，日志记录，隐式卸载功能，提升的权限，标准化的命令行，透明性，用于标准化设置自定义的转换以及管理员安装以可靠地提取文件。只是为了快速列出大公司。 此处的列表形式的优点 。 / p>

到目前为止，很多题外话了-让我们重点讲一下。可以使用哪些工具比较MSI文件？





商业工具



几个商业部署工具，例如 Installshield ， 高级安装程序 和 许多其他MSI工具 支持查看和比较MSI文件。也许我添加了太多链接，但让我使用我惯常的策略如果您链接到一个链接，您就链接到了每个人 –这样可以节省一些时间和一些Google搜索。



作为特别说明-一种怀旧的东西-我见过的最好的MSI-diff功能是在 Wise Package Studio 中。老实说，这比其他人高得多-始终工作，颜色编码整齐，易于理解。该工具不再按以下说明出售：要使用什么安装产品？ InstallShield，WiX，Wise，Advanced Installer等（如果您的公司中有打包团队，也许他们周围有备用许可证？）。





免费工具



商用工具不错，但是有也是可以用来比较MSI文件的几种免费替代方案-以下是其中的一些列表以及一些有关如何使用每种工具的提示（以一种非常简约的方式）。



dark.exe 添加了更多详细信息-这不是用于COM结构化存储的比较工具文件，但是可以将MSI文件反编译为WiX XML源文件并提取所有支持文件（图标，二进制文件，cabs，设置文件）-以后可以将它们与常规文本/二进制比较工具进行比较。



1。 Orca （MSI SDK）



微软的自己的 MSI SDK工具/查看器，名为 Orca 可以查看和编辑MSI文件，但是没有直接支持比较两个MSI文件（据我所知）。我想您可以导出表然后进行比较，但是其他工具具有更多内置功能。提到此选项是因为您可能已经安装了Orca，然后这可能是完成简单差异的一种快速方法。 穷人的选择。



您可能已经安装了安装程序。如果安装了Visual Studio，请尝试在 Program Files（x86）下搜索 Orca-x86_zh-cn.msi - $ c> -并安装它。然后在开始菜单中找到Orca。从技术上讲，Orca是作为 Windows SDK 的一部分安装的（大，但免费下载）。如果您没有安装Visual Studio，也许您认识这样做的人？只需让他们搜索此MSI并将其发送给您（这是一个很小的mb文件）-应该花费他们几秒钟。如果没有，您可以随时下载Windows SDK



2。 超级逆戟鲸 （免费的第三方工具）



Super Orca将允许对两个MSI文件进行初步比较。我的冒烟测试似乎表明，可以忽略诸如摘要流之类的高级字段。换句话说，一个直线表只是比较。可能还有其他限制。也许足够好？易于使用。



注意 ：我无法确定是否可以验证，但我相信此工具一次保存了我的MSI，没有警告。当时是非常不可取的。



3。 widiffdb .vbs （MSI SDK）



MSI SDK 具有一个VBScript，可用于查看两个MSI文件之间的差异。它被称为 widiffdb.vbs （ msdn ）。使用此工具，我可以看到Super Orca忽略的摘要流差异。任何MSI SDK都是权威的。


UPDATE ： github.com上的所有MSI SDK API脚本（实际的VBScript代码）。





  • 插入指向此类MSI SDK VBScript的完整列表-用于各种目的。不要混淆，只有 widiffdb.vbs 是比较MSI文件所必需的，但是有许多有用的脚本可用于其他目的。

  • 如果已安装Visual Studio，只需搜索 widiffdb.vbs 。使用 cscript.exe 启动，并将完整路径传递给两个MSI文件以进行比较。在控制台中输出。



用法：

  cscript.exe widiffdb.vbs设置1.msi设置2.msi

示例输出：

 属性值[ALLUSERS] {1}-> {2} 
属性值[MSIINSTALLPERUSER] {}-> {1} 
属性INSERT [MSIINSTALLPERUSER] 
 \005SummaryInformation [9] {{00000000-0000-0000-0000-0000000000000000}}-> {{00000000-0000-0000 -0000-000000000001}} 
 \005SummaryInformation [12] {28.03.2019 15:20:02}-> {28.03.2019 14:40:52} 
 \005SummaryInformation [13] { 28.03.2019 15:20:02}-> {28.03.2019 14:40:52} 
 \005SummaryInformation [15] {2}-> {10}

要查找脚本，可以在 Program Files（x86） （如果您已安装Visual Studio（它是Windows SDK的一部分，还将与Visual Studio一起安装））-（当前路径为： C：\Program Files（x86）\Windows套件\10\bin\10.0.17763.0\x86 -只需适当地替换版本号并您应该更快地找到MSI。）



4。 dark.exe （WiX工具包-开源）



dark.exe 来自 WiX工具集 （一种可能用于编译某些MSI文件的工具包）。此 dark.exe 是MSI文件的反汇编程序或反编译器。它将MSI文件转换为 wxs XML格式（WiX自己的格式首先用于编译MSI文件），以及许多提取的二进制文件（如果使用正确的反编译选项和标志）。



wxs 源文件可以作为常规文本源文件进行比较（我最喜欢的）该工具是超越比较，但它是一种商业工具-有很多文本比较工具-包括在Visual Studio中）。二进制文件显然可以进行二进制比较。例如，可以将任何提取的CAB文件与另一个MSI设置版本中的另一个相似的cab文件进行比较。



这里是示例命令行：

  dark.exe -x输出文件夹MySetup.msi




  • 在很多情况下，这将对MSI文件进行很好的比较，您应该能够确定真正的不同。


  • 提取的二进制文件可以是脚本文件（VBScript等），也可以是任意数量的其他二进制文件（例如，编译的DLL自定义操作）。在后一种情况下，您无法真正对其进行进一步的反编译-除非它是.NET二进制文件，并且您具有反编译此类二进制文件的专业知识。


  • 但是应该注意的是，使用完全相同的WiX源文件编译的WiX生成的MSI文件可能有所不同，有以下几个原因：




    • 同一WiX源文件也可以使用不同的编译器进行编译和链接器设置，并且可以通过几种不同的方式影响生成的MSI文件。要查看所有开关，请下载并安装WiX 并只需编写 candle.exe 或 light.exe 进入命令提示符，然后按 enter 。


    • 某些字段，例如包装GUID 和产品GUID ，可以在wxs文件中设置为自动生成。在这种情况下，生成的MSI文件中相应的结果字段显然对于每个构建都是不同的。




      • 我不此处提供了可以设置为自动生成哪些字段的完整列表（如果您知道的话，可以点击编辑并就地修改此字段）。


      • 提到的自动生成的字段也可以进行硬编码（这对于GUID包不好，但这又是一个长期的故事-只要知道如果发现两个MSI文件在同一个GUID包中是二进制不同的，则您遇到了严重的麻烦-如果它们在野外-Windows Installer会按照定义将它们视为同一文件）。打包代码应始终自动生成。题外话。



    • MSI文件本身显然具有不同的文件日期信息，这些信息已分别编译-仅说明





主题，但仍然很重要：您可以使用 dark.exe 来反编译使用WiX的刻录功能编译的可执行文件。这是WiX的 bootstrapper功能，用于依次安装一个或多个MSI和/或EXE文件-一个接一个。这些引导程序是EXE文件，您可以将它们解压缩为组成的MSI和/或EXE文件：

  dark.exe -x outputfolder setup.exe

只需打开命令提示符，CD到以下文件夹setup.exe驻留。然后指定上面的命令。具体示例： dark.exe -x输出文件夹MySetup.exe 。输出文件夹将包含几个子文件夹，其中包含提取的MSI和EXE文件以及刻录GUI的清单和资源文件。然后，可以如上所述将所有MSI文件进行反汇编，以生成WiX源文件（wxs）。



5。 InstEd （免费的第三方工具-具有可用的加号版本）



出于某种原因，我从未积极使用过此工具，而是对其进行了多次测试。再次测试它似乎确实可以比较两个MSI文件，尽管它来自一个奇怪的菜单选项（这使我认为该功能以前不起作用）。




  • 打开一个MSI，然后转到 Transform =>与...进行比较... 并浏览至您要与第一个MSI进行比较的MSI。

  • 比较似乎可以，并且我发现在摘要流-例如-但差异似乎没有显示出什么不同（除非我只是看不到）。

  • 要查看摘要流的变化，请打开两个文件在单独的InstEd实例中，然后转到 Tables =>两种情况下的摘要信息... 。现在比较属性表中的信息。或者，使用上面列出的 widiffdb.vbs 脚本。



6。 其他工具... （COM结构的存储文件查看器）



毫无疑问，还有许多其他工具可以查看COM结构的存储文件，但我认为上述选项对于大多数用户来说就足够了。我将添加一个链接到 installsite.org的MSI工具列表 。



7。 高级安装程序 （具有一些免费功能的商业工具）



此商业工具将能够充当查看器并允许一些基本操作MSI文件上运行，即使未运行完整许可证也是如此。令人高兴的是，您甚至不需要使用原始表，但是可以使用更好的用户界面来修复 MSI中的各种内容。例如，各种升级参数（在大型升级卸载失败时继续或失败等）。



在表编辑器视图中所做的更改（直接表视图）在其他向导视图中不可见。 此处解释了原因 。





链接




How can I do a "content compare" of two (or more) MSI files and see what is actually different inside the files - instead of doing a useless binary compare? (which obviously only tells me if I am dealing with copies of the same file or not).

Some relevant and typical problem scenarios:

  • Our build system spits out MSI files like crazy, and sometimes we need to figure out what differences exist between different MSI files (read: something changed, and now we are failing deployment).
  • We have MSI files compiled from the same sources in different locations, and some of them fail to run reporting System.BadImageFormatException - how can we debug what the differences in the MSI files are? (an answer dealing with this error specifically here: Are applications dependent on the environment where it was compiled?).
  • MSI files can be compiled with all kinds of tools, but for stackoverflow users such files are probably most commonly created using WiX or Visual Studio Installer Projects (free toolkits).

This is a Q/A-style question on the topic of comparing your compiled MSI files to determine what real "content differences" exist.

解决方案

Microsoft Orca: If you have Visual Studio installed, try searching for Orca-x86_en-us.msi - under Program Files (x86) - and install it. Then find Orca in the start menu.

  • Current path: C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86
  • Change version numbers as appropriate

About MSI Files

Roughly speaking MSI files are COM-structured storage files - essentially a file system within a file - with streams of different content, one of which is a stripped down SQL Server database (in the most generic of terms I believe). Provided the MSI files are readable, the content (of various formats and types) can be compared.

Tech Note: It is conceivable that an MSI which triggers a System.BadImageFormatException is just not runnable (msiexec.exe can't run it), but it may still be readable - and hence comparable (please add a comment to verify this if you experience it).

Streams: Some streams in the MSI are tables with string values. There may also be streams for embedded cab-archives used to store files to deploy, and tables with binary content only - such as the Binary table where compiled and uncompiled custom actions alike are stored along with other binary content the setup needs. And there is a special "summary stream" and a table with icons stored in their native, binary format, and the list goes on... For most of the tables we can compare the strings in each table pretty much like we compare text in a Word document (which also used to be OLE / COM files - though newer versions now use Open Office XML) and get a detailed report of differences. In order to do this, you obviously need a special-purpose tool for the job - one capable of finding its way though all the relevant streams. Some commercial and free tools for this are listed below.

Binary content: Before elaborating this, I should note that comparing content in the Binary Table, Cabs Table, Icon Table - or any other binary table, will generally allow you a binary compare only (particularly for compiled custom action dll and exe files). Script custom actions - in the binary table - can be compared as text, but compiled custom actions are binary compare only. So if your problem emanates from a compiled custom action, you can't really see it in a direct compare (you see the binary difference only). You need to hit your source control system to see what code was used for compiled custom actions of any kind - hopefully you have a good label practice so you can find the actual source code used in each setup. I don't use this practice, but for internal, corporate releases perhaps you can even include your debug-build dll for your compiled custom action, and attempt to attach the debugger to the running code to really figure out what is going on? I wouldn't use a debug mode dll for a public release though - unless I'd clarified any risks. Debug code may be riddled with (unexpected) debug message boxes (used as entry points to attach the debugger) and other problems that should never hit a production package.

Come to think of it, your cab files and icon files can definitely be compared to their corresponding versions in older (or newer) MSI files by using the technique to decompile MSI files using dark.exe - which is described below. Then, using a good compare tool (Beyond Compare is mentioned below), you can do a full diff on the cab file content between different MSI versions (and some of the files could be text files, that could be text compared). I guess cabs and icons are sort of "transparent binaries" in an open format as opposed to compiled binaries (with custom actions and more) which are not inherently decompilable or inspectable (unless you know how to decompile managed binaries).

In conclusion: MSI files are fully transparent with the exception of compiled custom actions. This transparency is one of the core benefits of MSI. Most Windows Installer benefits, over previous deployment technologies, generally center around corporate deployment benefits. Unfortunately developers may only see the bad aspects of MSI: the (potential) MSI anti-patterns (towards bottom - very messy and ad-hoc for now). Admittedly some of these problems are very serious and violate "the principle of least astonishment". Developers - why have other and equally important things to do - may frankly be left scratching their heads in disbelief.

Leave no mistake about it though: MSI has massive corporate deployment benefits (see same link as above, towards bottom). Condensed: reliable silent running, remote management, rollback, logging, implicit uninstall feature, elevated rights, standardized command line, transparency, transforms for standardized setup customization and admin install to reliably extract files. Just to name the big ones quickly. Benefits in list form here.

A lot of digressions so far - let's get to the point. What tools can be used to compare MSI files?

Commercial Tools

Several commercial deployment tools such as Installshield, Advanced Installer and many other MSI tools have support for viewing and comparing MSI files. Maybe I add too many links, but let me use my usual policy of "if you link to one, you link to everyone" - it should save some time and some Google searches.

As a special note - a nostalgic one - the best MSI-diff feature I ever saw was in Wise Package Studio. It was head and shoulders above the rest to be honest - always working, neatly color coded and just easy to comprehend. This tool is no longer for sale as described here: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc (if you have a packaging team in your corporation, maybe they have a spare license laying around?).

Free Tools

The commercial tools are good, but there are also several free alternatives that can be used to compare MSI files - and below is a list of some of them along with some hints for how to use each tool (in a rather minimalistic way).

There are some more details added for dark.exe - which is not a comparison tool for COM-structured storage files at all, but a way to decompile MSI files to WiX XML source files and extract all support files (icons, binaries, cabs, setup files) - allowing them to be compared with regular text / binary compare tools afterwards.

1. Orca (MSI SDK)

Microsoft's own MSI SDK tool / viewer called Orca can view MSI files and edit them, but there is no direct support for comparing two MSI files (that I know about). I suppose you could export the tables and then compare them, but other tools have more built-in features. This option is mentioned since you may already have Orca installed and then this is probably a quick way to get a simple diff done. The "poor man's option".

You may already have the installer. If you have Visual Studio installed, try searching for Orca-x86_en-us.msi - under Program Files (x86) - and install it. Then find Orca in the start menu. Technically Orca is installed as part of the Windows SDK (large, but free download). If you don't have Visual Studio installed, perhaps you know someone who does? Just have them search for this MSI and send you (it is a tiny half mb file) - should take them seconds. If not, you can always download the Windows SDK

2. Super Orca (free third party tool)

Super Orca will allow a rudimentary compare of two MSI files. My smoke test seems to reveal that advanced fields such as the Summary Stream may be ignored. In other words a straight table compare only. There could be other limitations. Maybe it is good enough? It is easy to use.

Note: I have not been able to verify for sure, but I believe this tool saved my MSI without warning once. That was very undesirable at the time.

3. widiffdb.vbs (MSI SDK)

The MSI SDK has a VBScript you can use to view differences between two MSI files. It is called widiffdb.vbs (msdn). With this tool I can see the Summary Stream differences ignored by Super Orca. Anything MSI SDK is authoritative.

UPDATE: All MSI SDK API scripts on github.com (the actual VBScript code).

  • Throwing in a link to the full list of such MSI SDK VBScripts - for various purposes. Don't be confused, only widiffdb.vbs is needed for comparing MSI files, but there are many useful scripts for other purposes to be found.
  • If you have Visual Studio installed, just search for widiffdb.vbs. Launch with cscript.exe and pass in full path to two MSI files to compare them. Output in console.

Usage:

cscript.exe widiffdb.vbs "Setup 1.msi" "Setup 2.msi"

Sample Output:

Property Value           [ALLUSERS] {1}->{2}
Property Value           [MSIINSTALLPERUSER] {}->{1}
Property INSERT          [MSIINSTALLPERUSER]
\005SummaryInformation   [9] {{00000000-0000-0000-0000-000000000000}}->{{00000000-0000-0000-0000-000000000001}}
\005SummaryInformation   [12] {28.03.2019 15:20:02}->{28.03.2019 14:40:52}
\005SummaryInformation   [13] {28.03.2019 15:20:02}->{28.03.2019 14:40:52}
\005SummaryInformation   [15] {2}->{10}

To find the script, you can search for it under Program Files (x86) if you have Visual Studio installed (it is part of the Windows SDK which will also be installed along with Visual Studio) - (currently the path is: C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86 - just replace the version numbers as appropriately and you should find the MSI quicker).

4. dark.exe (WiX toolkit - open source)

The dark.exe binary from the WiX toolset (a toolkit which was likely used to compile some of your MSI files). This dark.exe is a "disassembler" or "decompiler" for MSI files. It will convert MSI files to wxs XML format (WiX's own format used to compile MSI files in the first place), along with a number of extracted binary files (if you use the correct decompile options and flags).

The wxs source files can be compared as regular text source files (my favorite tool for this is Beyond Compare, but it is a commercial tool - there are plenty of text compare tools - including those in Visual Studio). The binary files can obviously be binary compared. Any extracted CAB file can be compared to another, similar cab file from another MSI setup version for example.

Here is a sample command line:

dark.exe -x outputfolder MySetup.msi

  • In many cases this will yield a very good compare of the MSI files and you should be able to determine what is really different.

  • The extracted binaries could be script files (VBScripts, etc...) or any number of other binaries (for example compiled DLL custom actions). In the latter case you can't really decompile it further - unless it is a .NET binary and you have expertise in decompiling such binaries.

  • However, it should be noted that WiX-generated MSI files compiled using the exact same WiX source files can be different for a couple of reasons:

    • The same WiX source file can also be compiled with different compiler and linker settings, and this can affect the generated MSI file in several different ways. To see all switches, download and install WiX and just write candle.exe or light.exe into a command prompt and hit enter.

    • Certain fields such as package GUIDs and product GUIDs can be set to auto-generate in the wxs file. The resultant, corresponding field in the generated MSI file will obviously be different for every build in this case.

      • I don't have a full list of what fields can be set to auto-generate at this point (if you know, maybe hit edit and modify this in situ).

      • The mentioned auto-generated fields can also be hard-coded (which is not good for the package GUID, but that is another, long story - just know that if you find two MSI files that are binary different with the same package GUID, then you are in serious trouble - if they are in the wild - Windows Installer will treat them as the same file by definition). Package codes should always be auto-generated. Digression.

    • The MSI files themselves obviously have different file date information having been compiled separately - just to state the obvious.

And a special note somewhat unrelated to the topic at hand, but important nonetheless: you can use dark.exe to decompile executables compiled with WiX's Burn feature. This is WiX's bootstrapper feature used to install one or more MSI and / or EXE files in sequence - one after the other. These bootstrappers are EXE files and you can decompress them into their constituent MSI and/or EXE files: 

dark.exe -x outputfolder setup.exe

Just open a command prompt, CD to the folder where the setup.exe resides. Then specify the above command. Concrete sample: dark.exe -x outputfolder MySetup.exe. The output folder will contain a couple of sub-folders containing both extracted MSI and EXE files and manifests and resource file for the Burn GUI. Any MSI files can then be disassembled as described above to produce a WiX source file (wxs).

5. InstEd (free third party tool - with plus version available)

For some reason I have never used this tool actively, but tested it several times. Testing it again it does seem to do the job of comparing two MSI files, albeit from a strange menu option (which made me think the feature did not work before).

  • Open an MSI, then go to Transform => Compare Against... and browse to the MSI you want to compare the first one to.
  • Comparison seems OK, and I see that there are changes in the Summary Stream - for example - but the diff doesn't seem to show what is different (unless I just don't see it).
  • To see the summary stream changes, open both files in separate InstEd instances and go Tables => Summary Info... in both instances. Now compare the information in the property sheets. Alternatively use the widiffdb.vbs script listed above.

6. Other Tools... (COM-structured storage file viewers)

There are no doubt many other tools capable of viewing COM-structured storage files, but I think the above options should suffice for most users. I'll add a link to installsite.org's list of MSI tools again.

7. Advanced Installer (commercial tool with some free features)

This commercial tool will be able to function as a viewer and allow some basic operations on MSI files even without running with a full license. The nice bit is that you don't even need to use the raw tables, but can use a much nicer user interface to "hotfix" various things in the MSI. For example various upgrade parameters (continue or fail when major upgrade uninstalls fail, etc...).

Changes made in the Table Editor view (straight-up table view) will not be visible in the other "wizard views". The reason for this is explained here.

Links

这篇关于如何比较两个（或多个）MSI文件的内容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆