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

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

Generally you would have read that after isolation is done, we should not modify the MSI. So how to do .local and .manifest in the same MSI. Actually you would be thinking: "What is the need to do both types in the same MSI?" This is because, recently, I came across a situation in which we needed to do isolation of a file for installation of application in Windows 2000 through .local method and for installation in Windows XP and Vista through .manifest method. This was needed to be done through same MSI. This is the solution. Create a .msi file with .local isolation method for windows 2000. Then create another .msi file with .manifest isolation. Note the visual difference of .manifest isolation file and the base MSI. Make all the differences seen in this to the .msi which was created with .local isolation. Then compile it. This will not get corrupted. Only the ones with .manifest isolation if recompiled again get corrupted. So take care of this and you can then conditionalize...

I have learnt an easy way of copying condition directly in one Custom Action from other. This is totally on my experience, and I have not found any material for it on net too. So here it goes... Suppose you are making a CustomAction2 and have added it in the sequence as shown : And now you have to mention the condition same as that of CustomAction1, which in this case is "NOT Installed AND NOT PATCH", you have to click on CustomAction1 in the sequence and it will be like this: You can see the Condition in the greyed area. You cannot copy it directly, but what you have to do is: go to any of the other tab from this situation, be it Properties or Details tab. All you have to do next is to come back to your Location tab. And here you see the result.The Condition is automatically copied to the CustomAction2. Go ahead and try this out. It is really fun and easy. It will save you some time too.