sade055

And want to keep a post for the latest version as well: Well detailed in MSDN and here is the link: http://msdn.microsoft.com/en-us/library/dd408114(v=vs.85).aspx

Windows XP/Windows 7 works under a locked down environment in most organisations. The MSI authors generally have to provide permissions to the installation directory, so that the users without admin rights are able to access and write data into the installation directory. When you set permissions, you are specifying what level of access the user has to the folder and its files and what users can do within that folder such as save, delete, or read files. If you would like to know how to set permissions through Powershell Script, then I would recommend you to read my new blog entry here: http://msiworld.blogspot.com/2012/01/my-first-powershell-script.html There are six standard permission types which apply to files and folders in Windows XP/Windows 7: Full Control Modify Read & Execute List Folder Contents Read Write Each level represents a different set of actions users can perform. See the table below for more information. For folders you can also set your own unique permission...

There are five properties which are required by every Microsoft installer to identify itself from other MSI. These properties are required to be present in every MSI. These are the five properties: 1) Product Name: It is the name of the application you mention in your MSI. 2) Product version: This is the version of the product which you give.. like 1.0.0 etc.. 3) Product code: It is the unique GUID for your MSI. 4) Product language: This is the numeric value of product and should be one of those entries mentioned in Template summary property in Summary information stream. 5) Manufacturer: This is the name of the manufacturer of the product. For future upgrades, it is recommended to add Upgrade code property in the package.

In any of these installation transactions, viz. initial installation, repair, reinstallation, on-demand installation or patching an MSI, The REINSTALLMODE has an affect on it. Here is what "amus" means: * a - Force all files to be reinstalled, regardless of version * m - Rewrite all registry keys that go to HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT * u - Rewrite all registry keys that go to HKEY_CURRENT_USER or HKEY_USERS * s - Reinstall shortcuts and icons The mentioning of "a" in amus forces the reinstallation of files on your machine irrespective of the file version rules. Every file updated by REINSTALL property will be updated in this case. The sequence of events which happen actually depend on the authoring of your patch. If your patch contains the full file, the installer will not access the source to reinstall that file, but if your file is the delta of the file, like an update to say ini file, then the patch will access first the machine file ...

SOURCEDIR property in MSI package refers to the location from where the MSI is installed in the machine. How do we use this property in our package. If you want to use a file which is kept in the source folder (next to where your MSI is placed), through Custom Action then you need to follow this procedure. The SOURCEDIR cannot be directly used in the package. If you read the logs then SOURCEDIR property is created and correctly pointed to the directory. But later the log shows that: Deleting SOURCEDIR... So the value of this property is deleted and the MSI does not get access to it. If you display message with [SOURCEDIR] property then it will be empty. The work around for this is that we can put an Action in the sequence called: "ResolveSource" after CostFinalize action. Then if you place your Custom Action after this action which refers to SOURCEDIR property then you will get the correct value of SOURCEDIR. Acknowledgement: I would like to thank my friend, Anurag, here who ...

Ever wondered how many properties are set or can be set during an installation? Here is a great page which you can refer to for all the properties you ever wish to hear about Windows installer. http://helpnet.acresso.com/robo/projects/helplibdevstudio9/IHelpPropReference.htm

We can easily use Set Property Custom Action to set Windows Installer Property, but sometimes we wish to set the property directly in VbScript, specially if we are taking an input from a user through VBScript. Hope this tip helps. To set property through VBScript we can use "Session" object like: Session.Property("ALLUSERS")="1" or we can directly use Property keyword like: Property("REBOOT")="ReallySuppress" The only catch here is that we cannot set INSTALLDIR property through the above method as the package uses Directory table to store the value of INSTALLDIR. We need to write the below VBScript to set INSTALLDIR: dim instpath instpath = "C:\newpath\newfolder" Session.TargetPath("INSTALLDIR")=instpath Remember to place this Custom Action after CostFinalize if you are changing the value of INSTALLDIR property in UI Sequence.

The installer sets properties using the following order of precedence. A property value in this list can override a value that comes after it and be overridden by a value coming before it in the list. 1) Properties specified by the operating environment. 2)Public properties set on the command line. 3)Public properties listed by the AdminProperties property set during an administrative installation. 4)Public or private properties set during the application of a transform. 5)Public or private property that set by authoring the Property table of the .MSI file.