I've created an installer using wix 3.6 which produces an msi file that includes several dialogs (EULA, install location, etc). I then create a self extracting zip file using WinZip Self Extractor in the "Software Installation" mode which kicks off the msi. All this works great.
However, some users have requested a "minimial" install mode that doesn't prompt for input, it just uses all the defaults and installs. This would be used for admin type installs as part of a larger install script. I can pass /qb to the msi and get the exact behavior they want, but if I pass /qb to the self extractor exe it doesn't pass it along to the msi like I want. I've looked through the WinZip Self Extractor documentation, but haven't found an answer. Any ideas on how to make this work?
I don't recommend using generic self-extracting executables like WinZip and others because they do not cache the MSI file. Future operations with the MSI including minor upgrades, patches, and repair may require the MSI to be provided with the name the self-extractor used (hopefully WinZip doesn't change that) and will default to the path (usually %TEMP%). Users are often very confused when this happens and can't upgrade or fix their installation.
Instead, I recommend using a Bootstrapper/Chainer designed to install packages. WiX v3.6+ comes with a new feature called Bundle that uses the new Burn engine to handle all the self-extracting scenarios, plus much much more. It takes a bit more work to get created up front but can behave exactly like you are asking in this question.
Probably not the answer you were looking for, but I highly recommend considering using a real bootstrapper/chainer instead of a self-extractor.
Related
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
I've added the following to my WIX template to prevent installation without entering values in a custom dialog i've made.
<Condition Message='This installation can only run in full UI mode.'>
<![CDATA[UILevel = 5]]>
</Condition>
When I try to uninstall the application I get this message, and I'm unable to proceed.
How do I fix this so that it does not apply on uninstall?
How can I forcibly uninstall this application?
Question 1: LaunchCondition
LaunchConditions must always evaluate to true for the setup to be able to install / run. There are some further details here: Failing condition wix (recommended for more context). When you invoke uninstall via Add / Remove Programs it will run the installer in silent mode (I believe UILevel = 2 or UILevel = 3), which fails your LaunchCondition since UILevel is not equal to 5.
OR Installed: A common technique to prevent LaunchConditions to trigger problems in other installation modes than fresh install, is to add OR Installed to the LaunchCondition in question. This will force the LaunchCondition to be true for all situations and modes where the product is already installed (modify, uninstall, repair, etc...).
So something like this could probably work as an updated condition:
Installed OR UILevel = 5
Wrong Approach?: With that said I would rather implement a check to determine if the value you need specified has been set on the command line via PUBLIC properties for a silent install, instead of that rather strange LaunchCondition checking the setup's GUI level. You can still implement this as a LaunchCondition - or use a custom action for more flexibility. The LaunchCondition would check for values for all critical setup parameters, and you would prevent them from running on uninstall and other modes with the OR Installed mechanism. Here is an answer on the topic of silent installation, transforms and public properties: How to make better use of MSI files (silent deployment is crucial for corporate deployment and software acceptance).
Question 2: Forcibly Uninstall
UPDATE: A couple of additional options listed towards the bottom for completeness.
2.1 - ARP Modify: I want to run the simplest option by you before going into too much crazy detail. Is the Modify option available for your setup in Add / Remove Programs? If so, please click it and see if you then can select remove from the setup's Modify dialogs. This should work (since you are generally not running the setup in silent mode when choosing Modify).
2.2 - Interactive msiexec.exe Uninstall Command: I forgot to add that you should be able to kick off an interactive uninstall via command line as follows: msiexec.exe /x {PRODUCT-GUID} /qf. Here is how you can find the product GUID: How can I find the product GUID of an installed MSI setup? So in summmary: you find the product GUID as explained in the link, and then you open a cmd.exe window and fire off the uninstall command indicated above.
2.3 - Microsoft FixIt: If the first option above is not available, there are several other options that could work, but before trying them I would recommend giving the Microsoft FixIt tool for installation / uninstallation problems a chance to see if this does the trick for you. Run it, select your installation and see if some auto-magic is there for you to get it uninstalled.
2.4 - Advanced (avoid if you can) - hack system-cached MSI: This answer will be the next step, if the above fails: I screwed up, how can I uninstall my program? Please let us know if the above does not work, and we will check the options here. I would just zip up the cached MSI and disable the launch condition, but this is way too hacky for comfort if you can avoid it.
UPDATE: The below was added, but not needed to solve the problem. It is not recommended, it is the last resort. Leaving the content in.
Finding Cached MSI: you can find the system cached MSI using Powershell as explained here. I will inline the Powershell command here:
gwmi -Query "SELECT Name,LocalPackage FROM Win32_Product WHERE
IdentifyingNumber='{PRODUCT-GUID}'" | Format-Table Name,
LocalPackage
You then open the cached file (make a backup of it first, or zip it) with Orca or an equivalent tool, and you make whatever change needed to get the uninstall to function correctly. This is not generally considered a sane approach - it is the last resort. And what you change in the MSI is different depending on what is wrong with it. This requires specialist MSI knowledge. It is easy to mess things up so uninstall becomes even more difficult.
I just saw you got the product uninstalled whilst writing this. Puh! Be glad you don't need this latter approach. I think I will commit it and set it to strikeout so it is visible but not recommended (if only for myself to reuse if needed).
UPDATE, some additional alternatives (not always applicable, included for reference and potential re-use): 1) If you have access to the original MSI used to install your software (it must be the exact copy of the MSI used to install), then you can try to double click it and this should take you into modify directly. 2) You can also double click the file in the system cache folder if you no longer have the original installation MSI. 3) It might be you can hotfix the uninstall string in the registry as well to force a non-silent uninstall:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall
There are probably further ways. For example 4) hack a transform to apply during uninstall, 5) patch the installed MSI (if it is in the wild with lots of installs everywhere), etc...
I'm using a WiX installer to install a Notes plugin. I use the IniFile action to set the fields in notes.ini telling Notes to load my plugin. I'm using WiX 3.7.1224.0
<IniFile Id="HLBridgeDLLINI" Action="addTag" Directory="LOTUSNOTESINIDIRECTORY" Name="Notes.ini" Section="Notes" Key="AddInMenus" Value="HLBridge.dll"/>
<IniFile Id="HLClientDLLINI" Action="addTag" Directory="LOTUSNOTESINIDIRECTORY" Name="Notes.ini" Section="Notes" Key="EXTMGR_ADDINS" Value="HLClient.dll"/>
Before running the installer, the notes.ini file is writable by Everyone. After the install, the Everyone user is missing from the security attributes. Is WiX doing this, presumably for security reasons? If so, is there a way to disable this? I can write a custom action to change the security back if I have to I suppose.
Short version
Custom permissioning would seem to be applied (unexpectedly) via a WiX element or a custom action during the installation process (other possible causes discussed below - maybe check the major upgrade file revert possibility in particular - or the group policy possibility).
Clues for debugging can be found in the WiX source, or the compiled MSI file, or in a verbose log file (to name a few places to start). Details for each option below.
The below was written very "organically" - it evolved a bit - so it is a bit redundant. I will leave it as it is.
Other Possible Causes
Major upgrade file revert: It is quite odd that the file has less rights after the install. Perhaps this indicates a group policy or a file recreate during installation? The latter sounds very unlikely for such an important file - but it could happen if the update is a major upgrade and the original MSI installed the INI file as a file (instead of as INI file entries) and set it to be a non-permanent file.
In this scenario the INI file will be uninstalled and then reinstalled - likely stripping it of any custom ACL permissioning (ACL permissions are very complicated, they can inherit and override, and deny or grant, etc...). Any custom INI entries added to the old file will also be wiped out - check for such missing custom entries after installation.
This is a common problem (major upgrade file revert): major upgrade file uninstall and reinstall making the file appear reverted or overwritten when it has been wiped out and installed fresh instead and can trigger many other problems than ACL issues.
Other potential sources for the unexpected permissioning are also possible:
repair / modify operation for another Lotus Notes-related MSI package targeting the same INI file?
another MSI run as part of the same setup bundle doing permissioning?
group policy / active directory processes enforcing standard ACLs? (sample)
an executable / service run in admin mode doing something funky?
scheduled tasks interference? (some possibilities)
logon scripts doing something funky? (very unlikely in your case, but login scripts can do pretty much "anything" - and they do)
some other, unexpected source. Something with admin rights does this - that is the obvious common denominator.
My 2 cents: if this is an in-house, corporate package, use group policy to apply permissioning instead and remove the operation from your package (unless you deploy to computers outside group policy control - but then you can have a special package which only does permissioning and keep permissioning out of your main package - making it less error prone).
ACLs
The problem you describe is very interesting. I am not aware of anything automatic in WiX that would meddle with ACLs, though I can not guarantee it. There are, however, constructs that are designed to change ACLs when you specify them explicitly - and you need to check your MSI for these constructs (described below)
But first of all: I ran a quick smoke test with a WiX MSI to see if I could replicate the problem, and I can not replicate it. My fear was that this could be something changed in a recent Windows Update. In other words some sort of security fix distributed without anyone's awareness which changes core functionality in Windows Installer (it wouldn't be the first one).
ACL-permissioning
Some info on how ACL permissioning can be implemented in your MSI. Essentially you can use ready-made WiX elements, or run your own custom action.
There are several WiX elements that deal with ACL-permissioning and they result either in settings added to standard, built-in MSI tables or they add entries to custom WiX tables. Look for these elements in your WiX source (if available) (samples):
Permission (maps to built-in, standard MSI LockPermissions table).
PermissionEx (WiX-specific Util extension permissioning - maps to custom WiX table).
PermissionEx (maps to built-in, standard MSI MsiLockPermissionsEx table - a feature added in Windows Installer version 5).
FileSharePermission (WiX-specific Util extension file share permissioning - maps to custom WiX table).
I am not sure why the WiX guys decided to support all these different permissioning options - there are surely good reasons - since it must be a lot of work to maintain for them. I have written permissoning code myself, and in my view it is a time bomb of conspiratory complexity to deal with. Permissions permute like you wouldn't believe, but that is off topic here. In my condensed view very few permissions make any sense, but full flexibility is allowed by ACL permissioning - all the rope you need to shoot yourself in the foot. I prefer the generic "macros": GenericAll="yes", GenericExecute="yes", GenericRead="yes", GenericRead="no", etc...
Additionally you can use custom actions to call command line permissioning tools such as subinacl.exe, cacls.exe, xcacls.exe, icacls.exe or several other ones - which I would definitely not recommend for reliability and security reasons. Custom actions are never preferable when there are other options: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
The Permission element I would not use for technical reasons, the built-in MsiLockPermissionsEx table I have never tested. The WiX-specific PermissionEx element is probably what I would choose to use if I needed this ACL permissioning at all.
Inspect MSI
If you have WiX source access, you should be able to find the permissioning elements or the custom action elements that cause the problem.
However, if you do not have WiX source access, you can also check your actual, compiled MSI file for any custom features that could apply custom permissioning. I would focus on the Custom Action table and any custom WiX / MSI tables found in the MSI in question.
In other words: inspect the compiled MSI file used for installation for custom actions and custom tables that are used to set ACLs. See MSDN for a list of standard MSI tables. Any table you don't find there is custom.
To inspect the MSI, use Orca or an equivalent tool. See this answer (towards bottom) for a list of tools you can use (commercial or free): How can I compare the content of two (or more) MSI files?
Verbose Logging
You can also do what I always do: create a proper, verbose log for the MSI install in question. This gives you something to start with to figure out what is happening - and as such it might in some cases be better than just inspecting the MSI. You can find some information on how to do logging here.
Alternatively, you can enable logging for all MSI installations. See installsite.org on logging (section "Globally for all setups on a machine") for how to do this. I prefer this default logging switched on for dev and test boxes, but it does affect installation performance and adds a lot of log files to the temp folder (that you can just zap once in a while). Typically you suddenly see an MSI error and you wish you had a log - now you can, always ready in %tmp%.
I would also make a note of what OS you are on, and determine if the problem is seen only on this OS? And this also involves figuring out if you have the latest hotfixes installed.
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
The same (similar) information written for system administrators.
I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.
I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.
There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.
So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.
Update: Tried adding the following to the MSI Command Line value in the Release section:
REINSTALLMODE=vamus
This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.
In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.
The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.
Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.
If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).
The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.
See my answer here.
I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus
You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.