New technologies, new ways of working is changing our everyday environment.
Application Virtualization is the hot topic these days with Windows 7 coming in picture and organizations across
the globe are integrating App-V in their portfolio of delivery mechanism.
It has been quite some time now that I started work on App-V but did not get a chance to post things on my blog
as my blog was primarily focussed on MSI. I have finally decided to post App-V posts as well on my blog from now
onwards. There are lots of issues we face in everyday work regarding the technology and we try to lookup for
solutions on internet. As a cliche: If someone has already invented the wheel, there is no point re-inventing it.
The sole purpose of my blog is to help others with whatever I learn. I have got numerous solutions for problems
which I have faced and I really thank all those who had posted their solutions on net. This blog is just my way
to contribute back to the society.
All you people out there, please help by commenting, voting, propagating and sharing my blog with your friends
and collegues but with due credit and acknowledgement to the material posted here with my name and blog url as I
still do hold the copyright of the posts here.
Thanks all for your support.
Piyush
Wednesday, July 27, 2011
Sunday, July 24, 2011
How to correctly display icons
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
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
Sunday, July 17, 2011
What's New in Windows Installer 5.0
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
Well detailed in MSDN and here is the link:
http://msdn.microsoft.com/en-us/library/dd408114(v=vs.85).aspx
New Properties in Windows Installer 4.0 and later
Found this very useful post in msiblogger.com and would like to keep a note for myself so posting it here. Thanks to msiblogger for this.
Microsoft has released Windows Installer Service 4.0 with Windows Vista. This new version of msi engine introduces some new properties which are exclusively available to msi based installations targeted for Windows Vista & later.
MSIARPSETTINGSIDENTIFIER – The MSIARPSETTINGSIDENTIFIER property contains a semi-colon delimited list of the registry locations where the application stores a user’s settings and preferences. During an operating system upgrade, this information can be used by the setup to improve the experience of users migrating applications.
MsiLogging – This property can be used to enable automatic logging within the msi package. This propety value can be set to MSI logging parameters within the property table. Some valid values of this property would be: iwe, iwearcmpvo. Setting this property is the same as running your msi package with the /l option to create a log file. Note:You cannot use the “+” and “*” values of the /L option in the property value.
MsiLogFileLocation – This read/write property can be used to specify the name and location of the log file created by the MsiLogging Property. Not setting this property will automatically create a log file in the user’s temp location, the value of which will be set to this property.
MsiSystemRebootPending – This property is set to 1 if the target system has a pending reboot. This property can be used by setup in a launch condition to determine if a reboot is pending on the system.
MsiRunningElevated – This property is set to 1 if the msi package is being run with elevated privileges. This property is similar to using the Privileges property in msi 3.1 and earlier.
MSIRESTARTMANAGERCONTROL - This property enables setup authors to specify whether the package will use the Restart Manager or FileInUse Dialog to handle locked files at installation time.
The default value of this property is ‘0’, which forces the setup to interact with Restart Manager in case a locked file is encountered by the msi package.
Setting this property to ‘Disable’ will force the msi package to use FileInUse Dialog instead.
This property can also be set to “DisableShutDown”, which will mitigate Restart Manager’s ability to restart the machine in case of a reboot being triggered by the windows installer package. Using this property however does not disable Restart Manager from identifying files locked by applications and displaying the Restart Manager dialog.
MsiRestartManagerSessionKey - This value of this property is set to the Restart Manager session by the Microsoft installer.
MSIDISABLERMRESTART – This property is used to determine how applications and services that have locked files that need to be updated, will be handled after the update.
Setting this property to ‘0’ will force all the services that were shut down during an update to be restarted and applications registered with the Restart Manager to be restarted after the update.
Setting this property to ‘1’ will force all the processes (services & applications) that were shutdown during an update to not be restarted.
MSIRMSHUTDOWN – This property is used to determine how applications and services that are using files affected by an update should be handled during an update.
Setting this property to ‘0’ will cause all the processes using files affected by the update to be shut down.
Setting this property to ‘1’ will force all the processes using files affected by the update to be shutdown even if they don’t respond to Restart Manager.
Setting this property to ‘2’ will cause the processes using files affected by the update to be shutdown only if they are registered to be restarted by the Restart Manager. If any process is not registered for a restart, then it will not be shut down.
MSIUSEREALADMINDETECTION – Setting this property to 1 will request the installer to use the actual user information when setting the AdminUser property.
Microsoft has released Windows Installer Service 4.0 with Windows Vista. This new version of msi engine introduces some new properties which are exclusively available to msi based installations targeted for Windows Vista & later.
MSIARPSETTINGSIDENTIFIER – The MSIARPSETTINGSIDENTIFIER property contains a semi-colon delimited list of the registry locations where the application stores a user’s settings and preferences. During an operating system upgrade, this information can be used by the setup to improve the experience of users migrating applications.
MsiLogging – This property can be used to enable automatic logging within the msi package. This propety value can be set to MSI logging parameters within the property table. Some valid values of this property would be: iwe, iwearcmpvo. Setting this property is the same as running your msi package with the /l option to create a log file. Note:You cannot use the “+” and “*” values of the /L option in the property value.
MsiLogFileLocation – This read/write property can be used to specify the name and location of the log file created by the MsiLogging Property. Not setting this property will automatically create a log file in the user’s temp location, the value of which will be set to this property.
MsiSystemRebootPending – This property is set to 1 if the target system has a pending reboot. This property can be used by setup in a launch condition to determine if a reboot is pending on the system.
MsiRunningElevated – This property is set to 1 if the msi package is being run with elevated privileges. This property is similar to using the Privileges property in msi 3.1 and earlier.
MSIRESTARTMANAGERCONTROL - This property enables setup authors to specify whether the package will use the Restart Manager or FileInUse Dialog to handle locked files at installation time.
The default value of this property is ‘0’, which forces the setup to interact with Restart Manager in case a locked file is encountered by the msi package.
Setting this property to ‘Disable’ will force the msi package to use FileInUse Dialog instead.
This property can also be set to “DisableShutDown”, which will mitigate Restart Manager’s ability to restart the machine in case of a reboot being triggered by the windows installer package. Using this property however does not disable Restart Manager from identifying files locked by applications and displaying the Restart Manager dialog.
MsiRestartManagerSessionKey - This value of this property is set to the Restart Manager session by the Microsoft installer.
MSIDISABLERMRESTART – This property is used to determine how applications and services that have locked files that need to be updated, will be handled after the update.
Setting this property to ‘0’ will force all the services that were shut down during an update to be restarted and applications registered with the Restart Manager to be restarted after the update.
Setting this property to ‘1’ will force all the processes (services & applications) that were shutdown during an update to not be restarted.
MSIRMSHUTDOWN – This property is used to determine how applications and services that are using files affected by an update should be handled during an update.
Setting this property to ‘0’ will cause all the processes using files affected by the update to be shut down.
Setting this property to ‘1’ will force all the processes using files affected by the update to be shutdown even if they don’t respond to Restart Manager.
Setting this property to ‘2’ will cause the processes using files affected by the update to be shutdown only if they are registered to be restarted by the Restart Manager. If any process is not registered for a restart, then it will not be shut down.
MSIUSEREALADMINDETECTION – Setting this property to 1 will request the installer to use the actual user information when setting the AdminUser property.
Sunday, July 03, 2011
Windows 7 Language Pack Installation and Un-Installation on 32 bit and 64 bit Machines
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 all these files and how they are related in MSI.
Lp.cab: This is the basic installer cab file of the language pack which you can get through the source or DVD
Setup.bat: This is the batch file to install the language pack as per the above command line.
Setup.vbs: This .vbs file locally calls the setup.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths.
Uninstall.bat: This is the batch file to un-install the language pack using the above mentioned command line.
Uninstall.vbs: This .vbs file locally calls the uninstall.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths. Also this when wrapped in MSI, you can un-install the package from Add/Remove Programs and the language pack can be un-installed.
After creating and adding these files to a temporary location, you can add 2 custom Actions, one for install and other for un-install to run the vbs files from installed filed.
The Installation Custom Action can be placed just before InstallFinalize with condition as NOT REMOVE, and the Un-Installation Custom Action can be placed just after InstallInitialize with condition as REMOVE.
Now since you have read this from Packaging perspective this goes well for both 32 bit and 64 bit machines. But if now you try to install this MSI from Deployment tool or any other deployment tool which uses system account to run, you will face an issue with the 64 bit machines.
The reason for not working in 64-bit machines is that when the MSI is run in system account all the scripts/batch file are run through cmd.exe which is in c:\windows\syswow64 folder. This does not work for dism command line and I had to use a workaround for this issue.
The work around is that you need to run the dism command from %windir%\Sysnative.
This works fine and I have inserted the below line in the batch file for both install and un-install before running the dism installation command:
cd %windir%\sysnative
So the batch file looks like:
Install:
@echo off
cd %windir%\sysnative
dism /online /add-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab
Uninstall:
@echo off
cd %windir%\sysnative
dism /online /remove-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab
I hope all this information will be helpful for you to create the language packs. It took me a week to figure these things out. Hope you will not face this difficulty.
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\
Here are the uses of all these files and how they are related in MSI.
Lp.cab: This is the basic installer cab file of the language pack which you can get through the source or DVD
Setup.bat: This is the batch file to install the language pack as per the above command line.
Setup.vbs: This .vbs file locally calls the setup.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths.
Uninstall.bat: This is the batch file to un-install the language pack using the above mentioned command line.
Uninstall.vbs: This .vbs file locally calls the uninstall.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths. Also this when wrapped in MSI, you can un-install the package from Add/Remove Programs and the language pack can be un-installed.
After creating and adding these files to a temporary location, you can add 2 custom Actions, one for install and other for un-install to run the vbs files from installed filed.
The Installation Custom Action can be placed just before InstallFinalize with condition as NOT REMOVE, and the Un-Installation Custom Action can be placed just after InstallInitialize with condition as REMOVE.
Now since you have read this from Packaging perspective this goes well for both 32 bit and 64 bit machines. But if now you try to install this MSI from Deployment tool or any other deployment tool which uses system account to run, you will face an issue with the 64 bit machines.
The reason for not working in 64-bit machines is that when the MSI is run in system account all the scripts/batch file are run through cmd.exe which is in c:\windows\syswow64 folder. This does not work for dism command line and I had to use a workaround for this issue.
The work around is that you need to run the dism command from %windir%\Sysnative.
This works fine and I have inserted the below line in the batch file for both install and un-install before running the dism installation command:
cd %windir%\sysnative
So the batch file looks like:
Install:
@echo off
cd %windir%\sysnative
dism /online /add-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab
Uninstall:
@echo off
cd %windir%\sysnative
dism /online /remove-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab
I hope all this information will be helpful for you to create the language packs. It took me a week to figure these things out. Hope you will not face this difficulty.
Context Menu Creation for gVIM application in x64 machine
I was stuck in an application where I had to use the 32 bit source for both 32 and 64 bit machines. The application seemed to work fine, except the context menu option in x64 machines.
I found a great post by David Vielmetter on his blog http://davidvielmetter.com/tricks/context-menu-issues-with-gvim-in-windows-7-x64/ and I was able to solve the issue. I think context menu many times create an issue in 64 bit machines and this is a good way to solve them (This is entirely my point of view). If someone has some better suggestions, they are most welcome to comment here. I too would like to learn more on how to create 64 bit context menu options.
I found a great post by David Vielmetter on his blog http://davidvielmetter.com/tricks/context-menu-issues-with-gvim-in-windows-7-x64/ and I was able to solve the issue. I think context menu many times create an issue in 64 bit machines and this is a good way to solve them (This is entirely my point of view). If someone has some better suggestions, they are most welcome to comment here. I too would like to learn more on how to create 64 bit context menu options.
Subscribe to:
Posts (Atom)