sade055

IIS Express 7.5 is a vendor MSI package and the MSI is created by WiX. Though there is no problem as such while customizing this application, but I found an issue while adding a shortcut to this application. While creating IIS Express 7.5 package recently, I faced an issue that I was not able to add shortcut in this application. This for the matter of fact I realized that the shortcut table did not exist in this application. The error which I was getting was "Field shortcut of table shortcut: Error retrieving shortcut of table" To get this error fixed, I added the shortcut table and following entries in _Validation table: After adding this I added CreateShortcuts Action in InstallExecuteSequence Table at Sequence 4500. This was because, since there was no shortcut table, the sequence too was missing from MSI. Due to this the shortcut was not getting created. Once I did both these things, the application is installed fine with the shorcut. This can be used with other missing t...

The primary key of the ICON table should have the extension as .exe or .ico, else the icon will not display properly. For example if the extension is abc.js then the same javascript icon will be shown in this case. If it is .txt then notepad icon will be displayed. Whatever be there in the [Binary], that does not matter if there is any other extension apart from .exe or .ico

Recently I had to package Window 7 MUI for around 13 languages, both for 32 bit and 64 bit machines. I could not get any complete documentation for Installing, Un-Installing and making it work with the Deployment tool. I thought to write this article so it reduces the work of people who still have to make Language packs as a package. Windows 7 Language Packs come in a DVD and generally have a cab file called, lp.cab for all the languages in their respective folders. Following are the main command lines to be used while installing and Un-installing the Language Packs: Installation: dism /online /add-package /quiet /norestart /packagepath:lp.cab and Un-Installation: dism /online /remove-package /quiet /norestart /packagepath:lp.cab The lp.cab file can be copied to a temp location by your MSI and then a setup.bat file would be required to run the above command line. I had copied lp.cab, setup.bat,setup.vbs, uninstall.bat and uninstall.vbs to “%windir%\temp\ ” folder. Here are the uses of ...

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

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

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

Packages which need to include or which capture files with a total size exceeding 2 GB, it's necessary to use some tricks. Usually the MSI with cabs compressed outside the MSI allows the maximum size of cab files to be 2 GB. If the cab size file tries to exceed 2 GB, then the WISE package compilation throws an error. For this you need to create separate features. In these separate features, distribute the files in the package so that the feature has a total file size of less than 2 GB. After this you need to go to Media option in Installation expert and choose option one cab file per feature. This will give you the MSI along with cab files which have size less than 2 GB. Since the total package size will be very big, the downloading of cab files while deploying and then uncompressing them, will take lots of time. So the other solution is to choose the option of Uncompressed Files outside MSI in the media option. This will save time during installation.

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.