Here is what I am dealing with. I have a WIX project, that outputs a MSI file. This works like a charm.
I got a new requirement, that I need to analyse in order to figure out how to approach it. As the new requirement is, I need to get as output, a ZIP file, that contains the files and folders as described in the WIX project...
I searched for the "ZIP" keyword on the official documentation, but did not have any luck in finding something helpful...Maybe some of you guys have an idea?
Obviously, I could use other tools to perform this, like maven and the maven assembly plugin, but that would cause maintenance issues, as there would be 2 different projects, 2 different technologies, and since the files and directories structure is quite big, this could cause issues like one developer modifying a project, and forgetting about the other..
So yeah...difficult question...any input would be welcomed :)
Thx
Administrative Installation: Windows Installer / MSI features a built-in capability to extract all files and make a "network installation point" (a network location where installation can be kicked off from to install on all workstations on the network - ensures all source files are available for repair operations and patching). This is called an administrative installation - in plain terms a glorified file extraction mechanism.
Given the availability of the administrative installation, is a ZIP file really necessary? I suppose you could zip up the extracted admin image? Note that any files that need to go to system, shared or userprofile folders may cause issues and prevent successful launching of your application from the extraction folder (obvious, just mentioning).
Command Line: Try it, from a cmd.exe command prompt (see above link for more details):
msiexec.exe /a MySetup.msi
You could set the Compressed="no" attribute of the Package element to create an uncompressed layout. The result could be easily zipped (excluding the *.msi file) by running any of the freely available command-line zippers (e. g. 7za.exe of 7-zip).
Note:
File elements can override the Compressed attribute of the package.
I would like to create a script that will update files in the (default) install location with files from the source location where needed, based on the .wxs files that I have. I need to get this info from the wxs files, because the installation dir structure differs from the source location dir structure.
This would speed up my development cycle by not requiring a complete MSI uninstall/install when I have only recompiled one DLL for instance.
Is there functionality available in the Wix toolset that can give me a list of corresponding source and destination paths or would I have to implement everything including parsing of the Wix XML files myself?
I did not see anything relevant in the List of Tools section of the Wix documentation.
Alternative Approach: I would suggest using the commercial file and directory syncing and comparison tool Beyond Compare to copy files to the destination directory with ease if this is just for QA. I guess you can use post build steps too, but Beyond Compare is very nice and reliable. It has the features you need for just about anything related to comparison of files and folders (not affiliated). You can let the application just sit there and you can do a full comparison on the fly whenever needed. Essential software for deployment people. Alternatives exist of course (list).
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 working on a program which uses Access 97 databases (with DAO350.DLL). My goal is to make this program use Access 2007 (and so ACEDAO.DLL) and then deploy the new version on several computers (win7 64bits sp1 without office at all), which don't necessarily had the previous version of the program installed.
I made a new setup by modifying the former setup of the program (created with Package & Deployment Wizard). I thought it was a good idea since PDW doesn't find all the dependencies of the program (former setup contained added-by-hand files) and so I added ACEDAO.DLL.
The setup is made of : Setup.exe, Setup.Lst (which list all files to install and their properties) and a bunch of .CAB archives that contain the files to install.
The line of Setup.Lst concerning ACEDAO is the following :
File97=#ACEDAO.dll,$(CommonFiles)\Microsoft Shared\OFFICE12\,$(DLLSelfRegister),$(Shared),08/21/11 04:52:00 PM,573440,12.0.6650.5000
When I execute Setup on an other pc, I get this error :
ACEDAO.DLL was loaded but entry point for DLLRegisterServer was not
found
I learned afterwards that ACEDAO does not contain DLLRegisterServer function, therefore it couldn't work.
Moreover, ACEDAO needs MSO.dll. When I add MSO to the Setup, this one keeps loading the last file (VB6FR.DLL) from [Bootstrap Files] section of the .Lst file forever :
Traitement de VB6FR.DLL (9/9)
My questions are :
What can I do to register ACEDAO using the setup ?
Any idea why the setup stops when I add MSO.dll ?
I apologize for the grammar quality, English isn't my native language.
Replacing/adding DLLs manually is not going to work, there is a large tree of additional file dependencies involved - for example the COM libraries that wrap ACEDAO.DLL driver.
You need to include the correct redistributable which is probably:
Microsoft Access Database Engine 2010 Redistributable
Your installer will need to run this to install all the files & prerequisites.
I've got a fairly large MVC2 project in TFS which gets built automatically on checkin (Continuous Integration)
At present, the fully built version is dumped on a network share on our dev IIS server. \\Server\wwwrootLatest
TFS of course creates lots of sub-folders since it's just doing a build, it isn't even aware that it's drop directory is a wwwroot.
This means that to actually USE the build, we need to go and manually create an IIS App which points at the appropriate directory - which defeats the whole object of the exercise.
When we do a manual publish to that server, we use "File System" as the method and just overwrite the files in the UNC share \\Server\wwwroot
(When publishing to other environments, we use full-on MSDeploy.)
What I'd like to do is convince TFS to do a "File system" publish after the build completes and duplicate what we do on a manual publish eg:
Drop directory is \\Server\Build which would result in something like \\Server\Build\Project\Date.Rev\
After that is complete, we want it to publish to \\Server\wwwrootLatest - we can then set up the App once which will always contain the latest version but will still have a full history if required.
The only examples I've been able to find use MSBuild commands in the build definition (fine) but all use MSDeploy to do a full-on publish. I'm not sure how to automate what I want to do
Any help appreciated.
In your drop folder a folder named _PublishedWebsites is generated automatically. It contains files you need to put in wwwroot. You can use CopyDirectory build activity to copy them automatically.