|Configuration Header Files|
The "MAKEMSI.MMH" header file could be used directly by anyone who wants complete control over the building of an MSI however most people are happy to use the "preferred MSI interface" I have created which provides a simpler framework to work with while still being quite flexible and configurable. The "options for commands" section of this manual describes how most of this configuration takes place.
You will typically wish to brand your created MSIs by modifying things like:
If you decide you wish to change something this may be for a specific MSI you create or it may want to apply to all (or most) of the MSI installers you will create.
For those values that apply to most (or all) MSI packages the best approach is to create a text file such as "BillSmith.MMH" which will contain all the configuration that Bill Smith wants to apply as defaults. These configuration options could still be overriden for specific MSI installers as required.
The above configuration should not require direct editing of files such as "DEPT.MMH" and "COMPANY.MMH", you typically create a header file which includes "DEPT.MMH" while setting up all the options and information required.
|Creating Your Own Configuration File|
You will probably use "ME.MMH" (or "DENNIS.MMH") as a starting point so copy this somewhere else and change its name (maybe "BillSmith.mmh"). You can create the environment variable "MAKEMSI_USER_FILES_PATH" so that it points to the directory containing the header file(s) so that MAKEMSI will "find" it.
|For Larger Companies|
Note that if you are part of one of many teams within a large company then you would wish to create at least 2 header files, one common one for your company ("CompanyName.MMH") and one for your team ("MyTeam.MMH"), each team would create their own team specific header file (probably modelled on yours).
Each teams header file ("MyTeam.MMH" etc) would include "CompanyName.MMH":
Any level can change any level below it and in some (rare) cases may need to override higher levels...
|Don't stop there...|
Note that if your team creates many different "classes" of MSI it would make sense to create a header for each of these classes (each of which could include "MyTeam.mmh").
Your goal should be to reduce to one the number of places that need to be changed to improve something or fix a bug (you don't want to have to fix 100 MSIs because each one of the scripts has the same bug). Not only that but if somethin is in 100 places you could argue that it needs to be tested 100 times.
I have seen 40 MSI's where each script is 2 lines (I have also actually created useful one line data driven scripts which only include a header file)! If you found a better way of doing "it" (or wish to fix a bug) then the single header file needs to be updated as the script only contains "configuration". Note that any bugs are very quickly located as each MSI is built in an identical manner and to a large degree testing one MSI tests them all.