For some time now I have been packaging for x64 and x86 machines, and have faced numerous issues while creating the MSI for x64 machines. Well MSI will mostly work in x86 because of less complexity of 32 bit machine. There always seems to be a problem when you try to install the application in 64 bit environment.
Registry Structure:
The Registries install differently in 32 and 64 bit machines. in 64 bit machines, there is a provision to install 32 bit applications registry and this goes in SysWOW64 folder.
By default all 32 bit installers install the registry in SysWOW64 hive. If you need to install the registries in normal mode as in directly in the registry as it was in 32 bit machines, then you need to change the Component in your MSI to 64 bit component. This will ensure that your registries are to be installed as 64 bit and not 32 bit.
You might face issue in compiling your 32 bit application with a 64 bit component. I would suggest you to compile your Application with 32 bit component and change the component attribute with ORCA later on.
Folder Structure:
I would like to share the 2 basic folders which are different in 64-bit machines.
• Program Files: There are two folders for Program Files in 64 bit machines and they are Program Files and Program Files (x86). All applications which have 64 bit installer are installed in "Program Files" folder, whereas all 32 bit applications are by default installed in "Program Files (x86) folder.
• System folder: The System 32 folder also behaves in the similar manner as Program Files and in this for 64 bit installers, the files which are to be placed in System 32 are directed to "System32" Folder only. The 32 bit installers however place these file in "SysWOW64" Folder.
Now the question comes to package the applications in such a way that we get desired output. I will list down certain scenarios and how to handle them in packaging. I hope to cover most as in whatever issues I have faced and your feedback for more scenarios is most welcome.
a) Scenario: In a capture application, files are getting installed in SysWOW64/Program Files (x86) folder when you want the files to be placed in System32/Program Files folder.
Resolution: You need to check the Summary section in your WISE Package Studio. If your package is marked as Intel,1033 (or Intel,xxxx), then you need to change this to x64,1033 (or x64,xxxx).
By doing this you are changing the installer type from 32 bit to 64 bit. You cannot install this package now on 32 bit machines and you will have to create a separate installer for that. I have done a lot of research and this only seems to be the most viable option as of now.
Also you need to change your directory in WISE package Studio/MSI.
There are additions of new already defined folders in MSI for 64 bit support. These folders are explained below:
[ProgramFiles64Folder] will redirect files to “Program Files" folder and [ProgramFilesFolder] will redirect the files to "Program Files (x86)" folder in 64 bit machines.
[System64Folder] will redirect files to "C:\Windows\System32" folder and [SystemFolder] will redirect the files to "C:\Windows\SysWOW64" folder in 64 bit machines.
Choose accordingly in your package. If there is still some problems, you can try making the components to be 64-Bit and try again.
b) Scenario: There is a vendor MSI which is 32 bit and install files to "Program Files (x86)" Folder in x64 machine. But due to the functionality of the application, you would require it to install to "Program Files" folder.
Resolution: If you are thinking that you will change the Summary section in MST file from Intel,1033 to x64,1033 and it will work, well you are thinking in right direction, but it does not work. You will have to change the summary section in MSI directly through ORCA and then do rest of the customizations in MST.
WIN64DUALFOLDERS determines what happens to the path variables while installation of an MSI. Based on the application type as in 64 bit or 32 bit, the paths are determined.
If it is a 64 bit installer then you will see something like this in the log file:
WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\ABC\XYZ\' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
This means that the file system redirection will not happen. All paths will be defined as desired.
For example:
ProgramFilesFolder will be C:\Program Files (x86)
ProgramFiles64Folder will be C:\Program Files
and so on...
The end result would be as expected.
The 64-bit msiexec.exe is used in the whole process.
If it is a 32 bit installer then you will see something like this in the log file:
WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
This means:
ProgramFilesFolder will be C:\Program Files (x86)
ProgramFiles64Folder will become C:\Program Files (x86)
I hope this will help you in Packaging your applications for 64 bit.
Thursday, September 08, 2011
Tuesday, August 16, 2011
Shortcut creation issue in Installshield/WISE Package Studio
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 tables as well. We need to add the entries in _Validation table for all the
tables which are missing for its every corresponding column.
Hope this will help you if you face similar issue in future.
Thursday, August 11, 2011
Installing executable from remote location by suppressing the Open File Prompt
Many times while running a script/application exe from a network we get an error that the application is not from a trusted source and if we want to install the particular application or not.
This error comes because the source is not digitally signed and the Operating System prompts to ask from user if it is a known source to user or if something malicious is being run from network. This is just to protect the end users from the malicious software or Virus attack.
Technically,
This behavior was introduced in Windows XP SP2 because of the addition of the Attachment Execution Services (AES). Every program that is run by using the ShellExecute() API passes through AES. AES considers the downloaded update file to be from the Internet Zone. Therefore, AESdisplays the Open File - Security Warning dialog box. AES examines the file to see whether the file has a file stream of the type Zone.Identifier. Then AES determines what zone the file is from and what level of protection to apply when the file is run.
You can use the below code to suppress this message for your application to work fine.
set oShell= CreateObject("Wscript.Shell")
set oEnv = oShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1
<Your Code here>
oEnv.Remove("SEE_MASK_NOZONECHECKS")
Please note that you should not set this as a permanent environment variable as it will disable all Zone Checking and it is not recommended.
This error comes because the source is not digitally signed and the Operating System prompts to ask from user if it is a known source to user or if something malicious is being run from network. This is just to protect the end users from the malicious software or Virus attack.
Technically,
This behavior was introduced in Windows XP SP2 because of the addition of the Attachment Execution Services (AES). Every program that is run by using the ShellExecute() API passes through AES. AES considers the downloaded update file to be from the Internet Zone. Therefore, AESdisplays the Open File - Security Warning dialog box. AES examines the file to see whether the file has a file stream of the type Zone.Identifier. Then AES determines what zone the file is from and what level of protection to apply when the file is run.
You can use the below code to suppress this message for your application to work fine.
set oShell= CreateObject("Wscript.Shell")
set oEnv = oShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1
<Your Code here>
oEnv.Remove("SEE_MASK_NOZONECHECKS")
Please note that you should not set this as a permanent environment variable as it will disable all Zone Checking and it is not recommended.
VB Script to check for Microsoft Office 2003 and Word 2007
I had written this script to check the presence of MS Office 2003 and Word 2007 on a machine before proceeding for installation. Here is the code:
officepath11= sProgramFilesDir & "\Microsoft Office\Office11\"
officepath12= sProgramFilesDir & "\Microsoft Office\Office12\"
'set File System Object
set fso=createobject("scripting.filesystemobject")
'Check if file exists for Office 2003 and if yes then its version
path11 = fso.GetAbsolutePathName("C:\Program Files (x86)\Microsoft Office\Office11\winword.exe")
if (fso.FileExists(path11)) then
returnstring11=fso.getfileversion(officepath11 & "winword.exe")
else
returnstring11="Null"
end if
'Check if file exists for Word 2007 and if yes then its version
path12 = fso.GetAbsolutePathName("C:\Program Files (x86)\Microsoft Office\Office12\winword.exe")
if (fso.FileExists(path12)) then
returnstring12=fso.getfileversion(officepath12 & "winword.exe")
else
returnstring12="Null"
end if
arr11=split(returnstring11,".")
arr12=split(returnstring12,".")
if (arr11(0)="11" AND arr12(0)="12") then
'msgbox "Office 2003 and word 2007 both are installed, continue with script below"
else
if (arr11(0)="11" AND arr12(0)="Null") then
msgbox "Please install Word 2007 before installing this application"
WScript.Quit
else
if (arr11(0)="Null" AND arr12(0)="12") then
msgbox "Please install Office 2003 before installing this application"
WScript.Quit
else
if (arr11(0)="Null" AND arr12(0)="Null") then
msgbox "Please install Office 2003 and Word 2007 before installing this application"
WScript.Quit
end if
end if
end if
end if
set fso=nothing
officepath11= sProgramFilesDir & "\Microsoft Office\Office11\"
officepath12= sProgramFilesDir & "\Microsoft Office\Office12\"
'set File System Object
set fso=createobject("scripting.filesystemobject")
'Check if file exists for Office 2003 and if yes then its version
path11 = fso.GetAbsolutePathName("C:\Program Files (x86)\Microsoft Office\Office11\winword.exe")
if (fso.FileExists(path11)) then
returnstring11=fso.getfileversion(officepath11 & "winword.exe")
else
returnstring11="Null"
end if
'Check if file exists for Word 2007 and if yes then its version
path12 = fso.GetAbsolutePathName("C:\Program Files (x86)\Microsoft Office\Office12\winword.exe")
if (fso.FileExists(path12)) then
returnstring12=fso.getfileversion(officepath12 & "winword.exe")
else
returnstring12="Null"
end if
arr11=split(returnstring11,".")
arr12=split(returnstring12,".")
if (arr11(0)="11" AND arr12(0)="12") then
'msgbox "Office 2003 and word 2007 both are installed, continue with script below"
else
if (arr11(0)="11" AND arr12(0)="Null") then
msgbox "Please install Word 2007 before installing this application"
WScript.Quit
else
if (arr11(0)="Null" AND arr12(0)="12") then
msgbox "Please install Office 2003 before installing this application"
WScript.Quit
else
if (arr11(0)="Null" AND arr12(0)="Null") then
msgbox "Please install Office 2003 and Word 2007 before installing this application"
WScript.Quit
end if
end if
end if
end if
set fso=nothing
Wednesday, August 10, 2011
Issues while launching and closing of App-V shortcuts
While launching your App-V shortcut, if you notice that the buffering launch on bottom right says 100% but the
launch does not disappear as per normal behaviour then you need to do some modification in your osd file.
This possible is a cause if your application is Java related. You need to modify the Subsystem value in your osd
file.
By default the osd file has this:
<subsystem VALUE = "windows"/>
You need to change this value to
<subsystem VALUE = "console"/>
If you face a similar problem while closing the application or your application does not close completely, then
you need to again tweek your osd file.
By default you have following in your OSD file:
<virtualenv TERMINATECHILDREN="FALSE">
You need to change the value as below:
<virtualenv TERMINATECHILDREN="TRUE">
This will terminate the any child application which is associated with this application and will help to shut
your application down.
launch does not disappear as per normal behaviour then you need to do some modification in your osd file.
This possible is a cause if your application is Java related. You need to modify the Subsystem value in your osd
file.
By default the osd file has this:
<subsystem VALUE = "windows"/>
You need to change this value to
<subsystem VALUE = "console"/>
If you face a similar problem while closing the application or your application does not close completely, then
you need to again tweek your osd file.
By default you have following in your OSD file:
<virtualenv TERMINATECHILDREN="FALSE">
You need to change the value as below:
<virtualenv TERMINATECHILDREN="TRUE">
This will terminate the any child application which is associated with this application and will help to shut
your application down.
Wednesday, July 27, 2011
Application Virtualization
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
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
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.
Subscribe to:
Posts (Atom)