msiexec does not pass parameters to custom action - properties

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

Related

TFS 2015 Can build variables access other build variables?

When I define a custom variable in the new TFS 2015 team build as follows:
Name: SomeOutput
Value: $(System.DefaultWorkingDirectory)\Some
...it doesn't seems to expand $(System.DefaultWorkingDirectory).
Is there a way around this?
EDIT:
At least it seems it's not expanded everywhere.
For example, in MSBuild-Arguments, /p:OUTPUT="$(SomeOutput)" is expanded to /p:OUTPUT="C:\TfsData\BuildAgents\_work\3\s\Some" but when i add a cmd line build task with tool set to cmd and parameter set to /k set, it prints
SOMEOUTPUT=$(System.DefaultWorkingDirectory)\Some
EDIT 2:
Here are my variables
This is my workflow step
And this is what the build prints
You can use the VSTS Variable Tasks extension from the Visual Studio Marketplace.
When you define a variable in the Variables screen and use other variables as value, they won't be expanded (as you may have expected). Instead the literal text is passed to the tasks in the workflow. Without this little task the following configuration won't work:
Variable Value
Build.DropLocation \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)
By adding the Expand variable(s) task to the top of your workflow, it will take care of the expansion, so any task below it will receive the value you're after.
https://github.com/jessehouwing/vsts-variable-tasks/wiki/Expand-Variable
PS: The new agent (version 2.x) auto-expands variables now.
It can be achieved.
You may need use % % instead of $ to call the variables in cmd to print the result. It is also necessary to add call in the front of the command. Here is a simple example:
Note: System.DefaultWorkingDirectory is not available in cmd (not sure why); you need use System_DefaultWorkingDirectory instead. Details can be viewed in the logs.
I had the same problem - wanted to piece together a path made up of several built-in variables and pass it to a PS script.
Workaround:
I ended up combining the variables in the actual script through the corresponding generated environment variables (for example $env:BUILD_SOURCESDIRECTORY).
Not what I had in mind originally, but it works at least. Drawback - if I need to change the path, I always have to change the PS script instead of a build variable.

How to include arguments for MSI installation using WMI

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

How can I write installation path to registry with custom delimiter in WiX?

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.

Windows 7 environment variable not working in path

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.

How to redirect input for customaction execommand

I'm trying to setup a custom action to initialize my SQLite database using the sqlite3.exe command line tool. In a command prompt I type the following: c:\sqlite3.exe database.db < sqlscript.sql
My Wix custom action falls apart in the ExeCommand attribute because I cannot seem to escape out the <.
<CustomAction Id="InitializeDatabase" FileKey="SQLiteEXE" ExeCommand="database.db < sqlscript.sql" Execute.../>
I've tried "&lt" as well.
I know I could just install an empty initiailzed database but I'm curious how to redirect inputs.
Thanks.
So, what exactly is happening when you say it falls apart? Does it compile?
Just so that we're on the same page, are you ending you XML entity with the semi-colon. You probably are, but it didn't come through in your code sample. Are you using:
<
If that doesn't work, you could try putting the command into a property and using CDATA tags, such as:
<Property Id="MyCommand">
<![CDATA[
database.db < sqlscript.sql
]]>
</Property>
and using that in the ExeCommand attribute:
ExeCommand="[MyCommand]"
That might work.
If you really have to call an EXE, I reccomend using the WiX QuietExec Custom Action pattern. Worse case you could install a .BAT file then use the cmd /c foo.bat command to call it. Then you wouldn't have to escape the <.
Otherwise I would search for an alternative to the EXE. I try to stick with data driven custom actions that run in process ( say C++ or C#/DTF ).
Quiet Execution Custom Action