MST corrupt after editing base MSI
I used the search on my subject but couldn't find any topics about it. So here's my problem.
I made a MSI-file for a custumer application. Because the application is either for testing or production environment, it has different ODBC data-sources and registry settings for each environment. I made 2 different MST's based on the MSI for these settings.
Later I added a mergemodule to the MSI. Now i can't install my MSI with one of the transforms files (MST's).
Don't the MST's automatically adjust to the MSI? [8D]
Or did i have the wrong approach on this matter and should i consider other solutions like:
- msi with subfeatures (1 main-feature, with 2 underlying sub-features?)
- two single msi's
I made a MSI-file for a custumer application. Because the application is either for testing or production environment, it has different ODBC data-sources and registry settings for each environment. I made 2 different MST's based on the MSI for these settings.
Later I added a mergemodule to the MSI. Now i can't install my MSI with one of the transforms files (MST's).
Don't the MST's automatically adjust to the MSI? [8D]
Or did i have the wrong approach on this matter and should i consider other solutions like:
- msi with subfeatures (1 main-feature, with 2 underlying sub-features?)
- two single msi's
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
kkaminsk
20 years ago
Posted by:
mickman
20 years ago
But when i change to working with feature how should i do this?
base feature (level = always install this feature? & required feature?)
|
|__ sub feature (level = custom?)
|
|__ sub feature (level = custom?)
I don't exactly know if this setting does what i want. What i want is:
base feature is required for install
1 of the subfeature can be installed via INSTALLLOCAL property
base feature (level = always install this feature? & required feature?)
|
|__ sub feature (level = custom?)
|
|__ sub feature (level = custom?)
I don't exactly know if this setting does what i want. What i want is:
base feature is required for install
1 of the subfeature can be installed via INSTALLLOCAL property
Posted by:
kkaminsk
20 years ago
Oh great, I am not the world expert on this as I have been trying to find some good understanding myself.
If you want the base feature to always install you got that set correctly but that can vary depending on how you install the MSI. If you want the other features to install on demand when used I would put them at the root level just like the base feature and leave them with a default value for the install level. If the main EXE is in one of the sub features you will have a sub feature and the base feature install. So you have to watch how the MSI is advertised in order to control which features install.
It's Friday and I am trying to sneak out of the office. If my answer is not helping just pester me some more.
If you want the base feature to always install you got that set correctly but that can vary depending on how you install the MSI. If you want the other features to install on demand when used I would put them at the root level just like the base feature and leave them with a default value for the install level. If the main EXE is in one of the sub features you will have a sub feature and the base feature install. So you have to watch how the MSI is advertised in order to control which features install.
It's Friday and I am trying to sneak out of the office. If my answer is not helping just pester me some more.
Posted by:
mickman
20 years ago
The software is one product meant to be installed on production and development environment.
So the base feature (parent) installs the dll's and executables.
In de sub-features (child) there are the same registry keys with different values.
So when the msi is installed via SMS the program is
for Development environment:
msiexec /i <msi> /qb! ADDLOCAL="base_feat,development"
and for Production environment:
msiexec /i <msi> /qb! ADDLOCAL="base_feat,production"
As far as i can see now with testing this works well.
So the base feature (parent) installs the dll's and executables.
In de sub-features (child) there are the same registry keys with different values.
So when the msi is installed via SMS the program is
for Development environment:
msiexec /i <msi> /qb! ADDLOCAL="base_feat,development"
and for Production environment:
msiexec /i <msi> /qb! ADDLOCAL="base_feat,production"
As far as i can see now with testing this works well.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.