Indeed, this is all explained in the MSI SDK (click ) document but it is a long read, technical and assumes that you know some of the concepts already. Therefore here are the basics.
This is the file that contains the instructions for MSIEXEC.EXE to install the application. The MSI file is a Database file format and is now the preferred application packaging format for the windows platform. Sometimes the MSI file gets too big and some or all of the files are placed in a .CAB file.
In the MSI world, if you didn't create the MSI file, you want to keep the MSI file from the developer intact. To make changes beyond what the original MSI does you use a transform. The transform is applied at the time that the MSI package is installed. Why is this a big deal? In the old days (that includes today as well!) if you would repackage an application and it would fail, the Original Developer of the application would sometimes refuse to support it since repackaging strips out their installation logic. In the Developer’s mind, you modified their application. With MSI and transforms you avoid that charade.
If you create your own MSI packages you can also use transforms to change some parameters for each department of your company. That way you have only one package to maintain and nobody can accuse you of doing a better package for one department vs. another. It’s the same bloody package.
Transform files are in fact MSI files with a different file extension. The contents of both files are merged together at install time. They are not supposed to add files to the package but there are way. Wise Package Studio does allow adding files using Transforms but they create a CAB file to bring files in without breaking the MSI rules.
This is another one of MS’ idea to prevent DLL HELL. Merge Modules are groups of shared DLLs and OCXs that depend on one another. If your SetupCapture picks up one or more shared DLLs for which there is a Merge Module for, then those files are removed from your package and the appropriate Merge Modules are substituted in its place.
When you go to edit a package that contains Merge Modules, you don't see the contents of the Merge Modules that make up your package. If you want to see them: Edit menu ->Preferences-> Installation Expert tab-> check the Show merge modules components.
These files are available for download through WPS, Wise Solutions Technical Support Center (for registered users only) and at http://www.installsite.org/ under Merge Modules. When you buy Wise Package Studio (WPS), they are also on the CD.
This is what MSIEXEC does during an installation if it runs into an error and can undo the changes it did up to the point that the error occurred.
n/a (Security? Everybody is admin in 9x!)
USERS (2/3 down the page)
Limited USERS (???)
Sucessor to Windows XP
This is the User Account type that prevents users from installing applications (err..almost!).
In the old days, LAN Admin would create the User accounts as administrators, install the all software the user needed into his profile and then make the user account a “Restricted User”. The real fun began when you had to maintain such a thing.
Today, you can use MSI to install applications that require administrator access for Restricted Users. It does this by running the MSI installer as a service on the target workstation.
If you install an application for all users on the computer (or assign software to the computer account via GPOs) the software is fully installed only for user that initiated the install. All other existing and future users of the computer will have their installation completed next time they login and/or launch the application. The process used to complete these installations on the fly is unofficially called “User profile fix-up detection”. This is in fact a special case of self-healing feature of MSI. The catch is that most MSI packages don’t do this well if at all. You can, however, tweak the MSI package using Transforms to perform the changes properly.
Err..Almost: Even Restricted users can install/run some unwanted applications. This include self-contained applications that require no installation per se and applications that install files to the user's own profile and keys to the User's registry hive. The latter does exist but are few since most home windows users run with an Administrator account. Developers are more than happy to trade their users' security for fewer support calls.
WPS is meant to repackage applications into MSIs whereas WfWI is meant to generate MSI packages from scratch or from a Visual C/C++ code (ie.: for developers). Hence, WfWI has no SetupCapture or Transform creation capability.
WfWI version 3.2 and lower had SetupCapture and Transform creation capability and was able to repackage applications into MSI, since then Wise has created 2 separate products lines.
In Wise Package Studio (WPS), after you capture an installation, it creates a WSI file along with the MSI file. You can edit the MSI file directly but it is preferred to recreate the MSI file using the WSI file. Doing so gives you more options when creating MSI packages.
In Wise Package Studio (WPS), this is the default path for the captured packages. It is selected at install time of WPS. It is meant to be used as a central location for all packages, source files, WSI files and many other shared resources. In it you have a projects folder. That is where you create sub-folders for each of your packaging projects.
SetupCapture is the program in Wise Package Studio (WPS) used to repackage an application’s setup.exe package into an MSI package. Usually you tell it to create a WSI file instead of an MSI file directly. The WSI file is the working file from which you later compile it, with the source files, into an MSI file.
Install Tailor is the program in Wise Package Studio (WPS) used to create Transforms (.MST) an application’s setup.exe package into an MSI package. Unlike SetupCapture, you create an MST file directly and edit the MST file directly.(there is no such thing as a WST file in Wise)
Install Tailor is the program in Wise Package Studio (WPS) used to edit MSI packaged and Transforms (.MST). The is also the tool you use to edit WSI working files from which you later compile it, with the source files, into an MSI file. (BTW: Yes this is the same tool in Wise for Windows Installer.)
Wise has 3 classes for their WPS product:
-Standard costs the least and includes WiseScript Express.
-Pro costs 2-3 time more that Standard but add Client/Server setup and the full WiseScript Editor. Pro also add the much touted “Virtual Capture” feature but few people use it and nobody in the newsgroups answers questions about it.
-Enterprise costs more than Pro and is targeted to places that have many packagers and need to track/coordinate their work. It adds more reports and few more features.
All 3 versions can share the same SharePoint provided that the versions are matched-up. Ie. WPS 4.62 Standard and WPS 4.62 Pro can use the same SharePoint .
If you upgrade the SharePoint (by upgrading one Workstation) the other lower versions of WPS will be locked out. The only thing that really locks them out is the Workbench database. None of the packages in the projects folder are changed. If you use the conflict resolution and package distribution functionality (of Pro and up) then those features will probably be affected too.
In MSI land this is usually a division in your package to separate major functions. For example in MS Office, Excel and Word are separate features of the Office MSI package. Features are also meant to be able to be complete by themselves. If feature share files and registry settings for some things like spell checking, those are usually spun off as a separate feature that Excel and Word depend on.
In Wise Package Studio when you capture a setup, it usually creates only one feature called Complete. You can add features manually or add them using a feature SetupCapture. A feature can also be sub-divided into Components.
You can even have feature that install automatically depending on conditions. These are called Conditional Features.
A grouping of files and/or registry keys that are usually related to one another. Similar to the idea of a feature but provides a small functionality of a feature. Different features can use the same components.
Note: Some MSI packagers like On Demand’s WinInstaller create one component for each registry entry and file. This makes the package hard to troubleshoot but also eliminates many ICE Errors.
This term is used over and over but is not explained well. It is a specific Registry key or File that a component sees as most critical. When an MSI-based application is launched, it checks these critical registry keys and files or KeyPaths. If one of them does not match with what is in the MSI then the component related to that KeyPath is re-installed. This process is known as self-healing.
The fun in troubleshooting MSI comes when the KeyPath is set to a moving target like a temporary file or volatile registry entry like “last run time” or size/location of a window. This in turns triggers self-healing. You can change the KeyPath for components in WPS.
Variables in MSI are called properties.
Then can be set in the MSI tables in the package, set using a custom action in the MSI package, as a parameter if launched through the command line or using a transform.
The SDK mentions many "predefined" properties and says that some are initialized at runtime. If their name is ALL_UPPERCASE then they are known as public properties which can be set from the command line.
MSI technology runs on scripting. You can add to this script as you see fit. The catch is that these Custom Actions are not logged and are not undoable during a rollback. They can be used to uninstall the old non-MSI version of an application and other non-trivial things. You can do very fancy things like using a Custom Action to call a DLL which tests unlock codes to your application.
If you want to install unattended and want to use all the defaults in the menus, launch the MSI from the command line with the –QN switch.
If you want to install unattended but need to change something in the menus, then you must use a transform and launch the MSI from the command line with the –QN switch.
If you will be using GPOs to launch the MSI packages the same rules apply except the -QN switch is implied.
This is the way that applications are made available to be installed without actually being installed. This is used for Install-on-Demand purposes. This feature is meant to be used when distributing the package via GPOs or SMS or ZENworks. The package is assigned (via GPO) to a user and if the user launches the shortcut or opens a file with an extension associated to that package, then the package is installed for that user. The shortcuts and file associations are also called Entry Points to the package.
If you install an application for all users on the computer (or assign software to the computer account via GPOs) the software is fully installed only for user that initiated the install. All other existing and future users of the computer will have their installation completed next time they login and/or launch the application using these special shortcuts. The process used to complete these installations on the fly is unofficially called “User profile fix-up detection”. This is in fact a special case of self-healing feature of MSI.
What happens when a file in the package already exists on the target PC? In the old days it was whatever the author of the setup.exe felt like and that created what is known as “DLL HELL”.
MSI has rules for this:
Most files (EXE, DLL, etc.) have version numbers inside (Right-click-> Properties -> Version tab to see them). If a file that exists in both the package and on the target PC, the file with the highest version number will be copied (or left) on the machine. This is regardless of the file date.
If one of the files doesn’t have version number then the file with the version number will be copied (or left) on the machine.
If the file already exists on the PC it is NOT overwritten.
In some cases you really need to break these rules. Use the “companion file” feature of MSI to do that which is covered in the FAQ.