sade055

WinMerge application has the same source for x86 and x64 machines. The application works fine when packaged in MSI for x86, but the same application will not work on x64 as the context menu option will not be visible. To get the context menu option, follow these steps: 1) Install the source on 64 bit machine and from INSTALLDIR, copy the ShellExtensionx64.dll file. 2) Register this Dll file and keep its registry information in a reg file. 3) The 32 bit version of this ShellExtension is ShellExtensionU.dll, hence make the component of this .dll conditionalized to be installed only on 32 bit machines. For this you can write the Condition as: (VersionNT32) 4) Create a 64 bit component and import ShellExtensionx64.dll and its registry in it. The condition to make this component install only in 64 bit machines is: (VersionNT64) 5) Also keep in mind to launch the application before taking a second snapshot of the application. This will include some HKCU registry keys which go in HKCU\Softwar...

I Recently got to know from one of my team mates that the RunOnce key only runs once for the administrator and it does not run for the users. Just wanted to share this piece of information will all.

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.

Self Heal and Repair are two different concepts in Windows Installer which people many times consider to be the same thing, however there is difference in these two. Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application. When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature , if any of the key paths is missing it will launch Repair. Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched. Repair of an MSI can be triggered by Repair button in Add/Remove programs Giving the command line msiexec /f{other option} {MSI name} Self Heal by advertised shortcut or other advertising information. Active setup Once the repair of the package is triggered, even with Self Heal, then the whole of the MSI is reinstalled. Then it does not see tha...

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 ...