Overriding default installation directories for MSI packages
Hi,
I am writing an automated MSI installation functionality for a provisioning product. I am using Windows Installer SDK (C++). I am targetting fairly barebones functionality - viz.
Reading the MSI database and based on the data from there
I intend to extract the data into an XML file (Phase 1), and let the user override defaults as part of a web UI (Phase 2). Following that, I will generate simple msiexec command lines and let an agent run those to deploy the software on managed nodes (Phase 3). Something that I expect to look like:
msiexec.exe /norestart /qb /i package.msi ADDLOCAL=Feature1 ADDLOCAL=Feature2 ... ADDLOCAL=FeatureN MYAPPDIR=D:\myapp
The constraint is that I cannot modify the .msi files, nor use any transforms. I need to carry out everything if possible through the property overrides on the command-line alone (using TARGETDIR, and INSTALLLEVEL/ADDLOCAL). If that's not possible I should detect that it's not and allow the user to override only that part of the functionality that is possible to override through the command-line.
Here is my two-fold problem:
I need a generic way to do this and so far I have had limited success following this
approach:
The above approach has the following drawbacks:
** First, I cannot quite understand where each package install gets the value of TARGETDIR from.
** Secondly, there are packages for which the directory columns of all the features is blank.
** Third, there are packages for which there are multiple features without a Feature_Parent in the Feature table.
Any pointers to a more generic approach will greatly help.
- Arindam
I am writing an automated MSI installation functionality for a provisioning product. I am using Windows Installer SDK (C++). I am targetting fairly barebones functionality - viz.
Reading the MSI database and based on the data from there
- Allowing the user to override the default installation directory
- Allowing the user to select a subset of features to install
I intend to extract the data into an XML file (Phase 1), and let the user override defaults as part of a web UI (Phase 2). Following that, I will generate simple msiexec command lines and let an agent run those to deploy the software on managed nodes (Phase 3). Something that I expect to look like:
msiexec.exe /norestart /qb /i package.msi ADDLOCAL=Feature1 ADDLOCAL=Feature2 ... ADDLOCAL=FeatureN MYAPPDIR=D:\myapp
The constraint is that I cannot modify the .msi files, nor use any transforms. I need to carry out everything if possible through the property overrides on the command-line alone (using TARGETDIR, and INSTALLLEVEL/ADDLOCAL). If that's not possible I should detect that it's not and allow the user to override only that part of the functionality that is possible to override through the command-line.
Here is my two-fold problem:
- I need to find an appropriate public property like TARGETDIR or MYAPPDIR or whatever - which can help me override the default install dir.
- I need to determine the default location at which the app will install. (Of course this could be in terms of properties like ProgramFilesFolder instead of paths like "C:\Program Files" - that resolution happens at deployment time).
I need a generic way to do this and so far I have had limited success following this
approach:
- Query the "Feature" table and find out the top level feature (with a NULL Feature_Parent) and its corresponding "Directory" identifier.
- Query the "Directory" table and try to figure out the value of that "Directory" id.
The above approach has the following drawbacks:
** First, I cannot quite understand where each package install gets the value of TARGETDIR from.
** Secondly, there are packages for which the directory columns of all the features is blank.
** Third, there are packages for which there are multiple features without a Feature_Parent in the Feature table.
Any pointers to a more generic approach will greatly help.
- Arindam
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
photozz
16 years ago
Unfortunately, all I can offer is insight, not solutions. In my experience, finding a common public variable to query is going to be a problem. in most packages, it *should* be something like INSTALDIR. I have seen packages that keep this blank in the MSI and set it at runtime through a setup.exe. I have also seen it left blank in the tables and set it with a custom action in the MSI Script.
To put it in plain English, Are you looking to develop some tool you can just drop an existing manufacturers MSI into and have a wrapper of some kind determine the install variables, then present the user a limited set of those choices, and then use the selections to install the software to the users system, modifying the install without a transform only through public properties?
If you were to do this for a limited set of software, you might have a shot as you could account for a limited number of variables. If this is going to be a generic tool, I would say you are going to run into a lot of problems. Many manufacturer MSI files are just moderately good to downright horrible in following standards.
To put it in plain English, Are you looking to develop some tool you can just drop an existing manufacturers MSI into and have a wrapper of some kind determine the install variables, then present the user a limited set of those choices, and then use the selections to install the software to the users system, modifying the install without a transform only through public properties?
If you were to do this for a limited set of software, you might have a shot as you could account for a limited number of variables. If this is going to be a generic tool, I would say you are going to run into a lot of problems. Many manufacturer MSI files are just moderately good to downright horrible in following standards.
Posted by:
aogilmor
16 years ago
Usually INSTALLDIR is the main installation directory. If it doesn't already exist you can create it in the Directory table using ProgramFilesFolder as directory parent and some other name as the default folder name.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
