Im having MSI ,for minor update ,i will be updating only build number with no product code change. i try to paramters to msiexex .
msiexec /i sample.msi Reinstall=ALL ReinstallMode=amus in command prompt.Inspite of setting in command prompt,I tried to update msi property through orca. I added 2 properties to Reinstallmode and reinstall properties to orca.But they are not working.It gives me error message.Product of same version has already installed.
one more question which i had is
I tried to set custom action condition property = "Not Installed" .SO tht during repair mode ,i will not invoke custom action.Only one time invokation.
If i try to run msiexec /i sample.msi Reinstallmode=amus Reinstall="All" will custom action be invoked or it will not invoke.
~Mahender
I suppose the properties you pass are not set because you missed the correct spelling. Both REINSTALL and REINSTALLMODE properties should be all UPPERCASE. Such uppercased properties are called public properties, and only public properties can be passed via command line.
Hope this helps.
Related
I am utilizing the WiX "Environment" element to set an environment variable.
<Environment Action="create" Name="My_Certificates" System="yes" Id="certificate_env" Value="[CERT_XML_PATH]" Permanent="yes" />
CERT_XML_PATH gets set to the following: c:\this\is\my\path\myfile.xml
If that file actually exists, the environment variable is set properly and points to the file.
If that particular file doesn't exist at the time of the install, the environment variable is created and set, but the path is truncated to remove the myfile.xml portion.
This installer is part of a larger suite. It has its own standalone MSI. Installing one of the packages creates this xml file, but not the particular one I'm working on. If the xml file has been created, everything works fine. But if this installer is ran first, it will set the environment variable to
The environment variable "My_Certificates" gets created, but set to:
c:\this\is\my\path\
Instead of:
c:\this\is\my\path\myfile.xml
Troubleshooting:
The install log shows the property being set to the proper location.
MSI (s) (70:80) [15:27:44:988]: PROPERTY CHANGE: Adding CERT_XML_PATH property. Its value is 'c:\this\is\my\path\myfile.xml'.
Then we see the installer doing a WriteEnvironmentStrings a utilizing the proper path, including the xml file.
MSI (s) (70:80) [15:27:50:644]: Executing op: UpdateEnvironmentStrings(Name=My_Certificates,Value=c:\this\is\my\path\myfile.xml,Delimiter=[~],Action=536870914,)
WriteEnvironmentStrings: Name: My_Certificates, Value: c:\this\is\my\path\myfile.xml, Action 536870914
screen shot of system variables showing it not set properly
Any insight into why the file name is being truncated would be greatly appreciated.
Found the issue. There is a custom action in the installer that is also trying to set the Environment Variable. When disabling that custom action, everything works as intended.
Based on the documentation and examples provided by the chef documentation https://docs.chef.io/resource_windows_package.html, there is a way to pass options to an MSI. However, it is not clear on how to pass multiple options and public properties.
I have tried the following:
windows_package 'some msi' do
action :install
source "http://some url#{node['some app']['install']['windows']['package']}"
installer_type :msi
options "RESTADDRESS=#{node['some app']['rest']['ipaddress']} RESTPORT=#{node['some app']['rest']['port']} /passive /L*V c:\temp\install.txt"
end
However, upon running it ignores the options and properties and the default dialogue for msi pops up.
All the examples I have found only use one option in the recipe.
Please provide an example where you can pass more that one option and public properties
public properties are available in the msi documentation
http://www.advancedinstaller.com/user-guide/msiexec.html
The Chef source points to MSI installs calling this line for actually performing the installation.
This means the command becomes:
msiexec /qn /i "http://some url#{node['some app']['install']['windows']['package']}" RESTADDRESS=#{node['some app']['rest']['ipaddress']} RESTPORT=#{node['some app']['rest']['port']} /passive /L*V c:\temp\install.txt
This should have the same failure mode that Chef is showing you, and help you get a little further along.
Also, it appears you might need to escape your backslashes in the final c:\temp\install.txt.
When I create exe within the C:\Program Files\dotNetInstaller\bin folder, and run it, it works perfect, install perfect, but when I try to install that exe from any other location/path, the error appears "The installation package could not be opened. Verify that the package exists and that you can access it. etc....."
I created an exe and moved to another XP system, on that system, it again gives me error ?
whats the solution ? Is there any admin rights issue ?
I have tried with both TRUE and FALSE of Administrator_Required option.
any idea how can I solve this issue ?
The issue is resolved now.
I should have written #CABPATH\ in the MSI->Package field. Before I was writing #TEMPPATH\
I think you can should add the location:
C:\Program Files\dotNetInstaller\bin
in the PATH environment variable. Follow the steps: Go to
My Computer->Right click->Properties->Advanced System Settings
->Click Environmental Variables. Now click PATH and then click EDIT.
In the variable value field, go to the end and append ';' (without quotes) and then add the above path.
I am using WiX 3.5 and making an installer. I have used heat.exe to bundle all the files.
It produced a WiX file. I referred in main wxs files as componentgroup ref. When I build my installer, it throws the following exception.
light.exe : error LGHT0103 : The system cannot find the file
'..........\target\tmp-release\jboss-eap-5.0\jboss-as\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet\ReadOnlyAccessFilter.class'
with type ''.
It is able load many files from this location, except the above file, even though the file is present.
Looks like you've hit the linker bug. As far as I can see, it was already reported to the WiX team, and was scheduled for v4.0. The comment to the issue states the path is more than 255 characters, so a possible workaround for you is to re-work the files/folders layout to avoid the paths of that length.
Hope this helps.
The answer of Ravz1234 works ! I used it with a environment variable e.g. env.SourcePath.
1) Set an environment variable to show on your Source Dir e.g. C:\SourceDir
2) On heat.exe add the argument -var env.SourcePath along with the other arguments
I used the variable for the directory, sys.SOURCEFILEDIR, and it worked well.
I'm using setup.exe and setupbld.exe (from %WixProramFolder%\bin)to make a
bootstrapper for my installer. Everything is ok except:
I want to get current directory of setup.exe but:
When I use property "CURRENTDIRECTORY", I will get wrong value if I run
command line in cmd.exe: "C:>"D:\setup.exe"". "CURRENTDIRECTORY" is "C:\"
but "D:\" is true.
When I use property "SOURCEDIR", setup.exe will extract setup.msi to
"%Temp%{ProductID}\setup.msi" and "SOURCEDIR" is "%Temp%{ProductID}\" but
expected is "D:\"
Anybody can help me? It make me headache this time :-(
Sorry about my English.
I had this same issue last week with a DB backup that I needed to restore as part of the install. I didn't want to include in the installer as it is likely that it will be updated and even when compressed is ~168Mb.
In the end I included the file into the installer so that it got installed to the application install directory and set Compressed="no" on the file so it is an external dependency. This is not ideal but the only way I could get it to work.