I'm using wmi along with the 'call install true...' format to install an msi remotely:
wmic /node:"[host]" /user:"[user]" /password:"[password]" ENVIRONMENT="RELEASE" product call install true, "", "\\[host]\D$\WebsitesDirectory\[name].msi"
This works fine except that I can't get the format right to include the command line arguments I would normally use with msiexec. I have declared a variable called "ENVIRONMENT" in Wix. In this case, it should be ENVIRONMENT="RELEASE". Can anyone show me the correct format or point me towards the documentation that shows it?
I think I've found the answer. It appears the arguments go into the first pair of quotes after 'true':
... product call install true, "ENVIRONMENT=RELEASE", ...
Related
In CMakeLists.txt I write:
INCLUDE(CheckLibraryExists)
check_library_exists("libcurl" "" "" HAVE_CURL)
HAVE_CURL is always false, even if libcurl installed, and this function not causes fatal errors.
To check why a a try-compile fails, you can run CMake with the --debug-trycompile option, which will leave behind the buildsystem for the last try_compile command (these are used internally by all the Check... modules).
I didn't run the check, but I looked at the code of CheckLibraryExists, and it is apparently mandatory to specify a function to look for in that library (the second argument to check_library_exists).
Is there a way to detect the exist status of WebPICmd.exe (Command line version of WebPlatformInstaller), so that I can use it in my script.
I need to know if installation of particular product succeeded or not. (Trying to install PHP53, which seems to fail randomly due to download failures)
This can be detected using $LASTEXITCODE variable in PowerShell.
In dos mode it should be LASTERRORLEVEL.
Remember to check this variable immediately after running the WebPICmd.exe so that it's return code is not overwritten by something else down the line.
I would like to write a value to registry which consists of installation path and some additional path. Delimiter must be '/', e.g.
Value="[INSTALLLOCATION]/folder1/folder2"
How can I format this value so that installation path will be also with '/' delimiter instead of '\'?
MSI formatting doesn't support this. You'd have to write a custom action that read the property, reformatted the string and wrote it to a new property ( INSTALLLOCATIONFORMATTED) then you could use that property in the Registry table.
The bigger question and simpler answer though is .... "why?"
Are you doing something like file://c:/foo/bar.txt ?
file://C:\foo\bar.txt should work also as \ is the standard on the Windows Platform. It's probably better that whatever code reads this registry value be modified to accept \ instead of /. This results in a simpler and less fragile installer.
I am trying to set up some path using environment variable.
I added an environment variable "MAVEN_HOME" with the value "C:\maven".
Then in the path I added "%MAVEN_HOME%\bin;...rest".
When I type "echo $MAVEN_HOME%" I get the correct "C:\maven" printed on the screen.
But when I type "mvn" which is a batch file in the "bin" directory, it can't find it.
So, I manually added the entire path in PATH.
"C:\maven\bin;...rest"
and it was able to find "mvn" and execute it.
Could someone help me what I did wrong?
Check if there is a space character between the previous path and the next:
Incorrect:
c:\path1; c:\Maven\bin\; c:\path2\
Correct:
c:\path1;c:\Maven\bin\;c:\path2\
I had exactly the same problem, to solve it, you can do one of two things:
Put all variables in System Variables instead of User and add the ones you want to PATH
Or
Put all variables in User Variables, and create or edit the PATH variables in User Variable, not In System. The Path variables in System don't expand the User Variables.
If the above are all correct, but the problem is still present, you need to check the system Registry, in HKEY_CURRENT_USER\Environment, to make sure the "PATH" key type is REG_EXPAND_SZ (not REG_SZ).
My issue turned out to be embarrassingly simple:
Restart command prompt and the new variables should update
Things like having %PATH% or spaces between items in your path will break it. Be warned.
Yes, windows paths that include spaces will cause errors. For example an application added this to the front of the system %PATH% variable definition:
C:\Program Files (x86)\WebEx\Productivity Tools;C:\Sybase\IQ-16_0\Bin64;
which caused all of the paths in %PATH% to not be set in the cmd window.
My solution is to demarcate the extended path variable in double quotes where needed:
"C:\Program Files (x86)\WebEx\Productivity Tools";C:\Sybase\IQ-16_0\Bin64;
The spaces are therefore ignored and the full path variable is parsed properly.
%M2% and %JAVA_HOME% need to be added to a PATH variable in the USER variables, not the SYSTEM variables.
If there is any error at all in the PATH windows will silently disregard it. Things like having %PATH% or spaces between items in your path will break it. Be warned
Also worth making sure you're using the command prompt as an administrator - the system lock on my work machine meant that the standard cmd just reported mvn could not be found when typing
mvn --version
To use click 'start > all programs > accessories', right-click on 'command prompt' and select 'run as administrator'.
To address this problem, I have used setx command which try to set user level variables.
I used below...
setx JAVA_HOME "C:\Program Files\Java\jdk1.8.0_92"
setx PATH %JAVA_HOME%\bin
NOTE: Windows try to append provided variable value to existing variable value. So no need to give extra %PATH%... something like %JAVA_HOME%\bin;%PATH%
If the PATH value would be too long after your user's PATH variable has been concatenated onto the environment PATH variable, Windows will silently fail to concatenate the user PATH variable.
This can easily happen after new software is installed and adds something to PATH, thereby breaking existing installed software. Windows fail!
The best fix is to edit one of the PATH variables in the Control Panel and remove entries you don't need. Then open a new CMD window and see if all entries are shown in "echo %PATH%".
I had this problem in Windows 10 and it seemed to be solved after I closed "explorer.exe" in the Task Manager.
In my Windows 7.
// not working for me
D:\php\php-7.2.6-nts\php.exe
// works fine
D:\php\php-7.2.6-nts
I had the same problem, I fixed it by removing PATHEXT from user variable. It must only exist in System variable with .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Also remove the variable from user to system and only include that path on user variable
Copy the value of path to notepad and check if this corresponds with the echo %path% in terminal window and make changes if needed. Then delete the old path value and paste the notepad value back in.
I assume some invisible character entered there by some installation corrupted the path value.
Make sure both your System and User paths are set correctly.
I have a custom action inside an MSI installer that makes some changes to some configuration file. my requirement is to run the installation in silent mode so I am using msiexec.
Here is the command:
msiexec /i myInstaller.msi /l* out.txt myContextParameter=value1
myContextParameter is never passed to the custom action so when I do
context.Parameters["myContextParameter"] I get a null value.
When I run my MSI in UI mode the parameter is passed correctly. I also made sure the name of the property is correctly set in the CustomActionData.
I've been beating my head against the wall on this one, so here's what I found out:
You have to set your parameters on the commandline, as well as on the "CustomActionData" property on each of your Custom Actions (whatever you have under Install, Commit, etc)
Your commandline will look something like this:
msiexec /i myInstaller.msi MYFIRSTPARAM=VALUE1 MYSECONDPARAM=VALUE2
Then, your CustomActionData should look like this:
/myfirstparam=[MYFIRSTPARAM] /mysecondparam=[MYSECONDPARAM]
Now, here's a bunch of special cases:
It looks like #Klaus is right, you need to use ALLCAPS in your parameter names.
if your values contain spaces, you'll need quotes around them in both the commandline and your CustomActionData properties, as in:
msiexec /i myInstaller.msi MYFIRSTPARAM="VALUE1" MYSECONDPARAM="VALUE2"
/myfirstparam="[MYFIRSTPARAM]" /mysecondparam="[MYSECONDPARAM]"
if your values end with a slash, like most file paths do, you'll have a weird problem: when the msiexec builds your customactiondata, it'll create this string:
/myfirstparam="C:\myfile\" /mysecondparam="C:\myfile\"
it doesn't matter if you use quotes on the commandline or not, if that slash is the last character on your value, it will effectively be read as an escape character, and will escape the quote in your customactiondata property. This causes havoc. The solution is to either 1) add a space between your parameter and the last quote, and then remember to trim() it in your code somewhere, or 2) add and extra slash between your parameter and quote, in order to escape the escape character. See both methods below:
/myfirstparam="[MYFIRSTPARAM] " /mysecondparam="[MYSECONDPARAM]\"
Hope that helps.
MixedCase properties are "private" and will not be passed in from the command line.
ALLCAPS properties are "public" and can be passed in on the command line.
However only secure public properties are passed through to the 'server' (i.e. retained during UAC elevation). See the SecureCustomProperties property documentation.
Assuming you're trying to access this property in a deferred CA, this is happening on the server side so you need to use a public property (all caps) that is also marked as secure.
Here's an example using WiX:
<Property Id="MYPUBLICPROPERTY" Secure="yes" Value="{}">
If you want to be able to pass parameters from the outside you need to use ALLCAPS in your parameter names. I know it sounds weird, but try it! :-)
I know this is an old thread, but I tried a variety of things here and it seemed that I was at a loss. I then found the following thread on msdn:
http://social.msdn.microsoft.com/Forums/windows/en-US/8dd009ce-52d5-4737-98c8-89d9831ab60b/unable-to-pass-parameters-to-msi-thro-msiexec-via-command-prompt?forum=winformssetup&prof=required
Viewing the MSI in ORCA, you can see a few entries under "CustomAction." These Entries will basically override the values passed in from the command prompt. If you simply delete the entries in the CustomAction Table like: "CustomTextA_SetProperty_EDIT1" and then save the MSI (Save AS has a different behavior in ORCA). You can then pass the Property Values from the command line to the MSI. This will allow me to install remotely using msiexec and I am now be able to pass the parameters to the install via the command line. I imagine this happens because the logic for the CustomAction values is executed after having populated the property values from the command line which means that the CustomAction values overwrite the command line populated values.
There is also a link at the bottom of the thread to do some manipulation in VS as opposed to ORCA.
http://blogs.technet.com/b/alipka/archive/2007/04/20/how-to-use-custom-actions-in-visual-studio-setup-project-msi-from-command-line.aspx