I need to use the built-in variable [ComputerName] in a property in a Transforms.xml WiX file.
What I'm doing: <Property Id="MYCOMPUTERNAME" VALUE="[ComputerName]" />
What shows up is: "[ComputerName]"
That's not what I want.
I want the real computer name made available to the Property "MYCOMPUTERNAME".
Has anyone tried this successfully and how? Thank you.
WiX has a way to access environment variables. Check out the tutorial:
http://wix.tramontana.co.hu/tutorial/com-expression-syntax-miscellanea/expression-syntax
I think the syntax you would use is this, but I haven't tested it.
Related
If I put a hard-coded value it works fine
<Log PathVariable="C:\myProjectDir\myLogs\log.txt"/>
But if I make a separate variable and replace the hard-code, it does NOT work
<Log PathVariable="[LogLocation]"/>
<Variable Name="LogLocation" bal:Overridable="no" Type="string" Value="C:\myProjectDir\myLogs\log.txt" Persisted="yes"/>
I found something on the lines of <WixVariable Id="WixBundleLog"/> but I don't really know how to use it.
My end goal here is that I have a bootstrapper application and I want to change the location where logs of my msi and exe installation is created
I able able to change a Variable element value using _bootstrapper.Engine.StringVariables["LogLocation"] = "C:\ProjectGorilla\logs\log.txt"
Using the above code in C#, the Variable Id="LogLocation" is changed but that change is not reflected in Log element's PathVariable
So, my question is how can I put a variable in PathVariable attribute of Log element
Thanks in advance :)
According to the documentation, the PathVariable attribute is:
Name of a Variable that will hold the path to the log file. An empty value will cause the variable to not be set. The default is "WixBundleLog".
PathVariable does not specify the path where the (bundle) log will be written. It is a variable that the BA is supposed to read if it wants to copy the file somewhere else. The Burn engine never reads this variable's value so changing it during runtime won't do anything.
The (bundle) log is created (https://github.com/wixtoolset/wix3/blob/58abd6993afba08b39e37b0e76b1790161df9231/src/burn/engine/engine.cpp#L499) before loading the BootstrapperApplication (https://github.com/wixtoolset/wix3/blob/58abd6993afba08b39e37b0e76b1790161df9231/src/burn/engine/engine.cpp#L545). There is no way for the BA to change the path.
The package (MSI, EXE, etc) log locations work the same way today as the bundle log. However since they are created after loading the BA, it's theoretically possible that someone could implement a feature so that the BA can change their path.
I am using a WiX bundle with Xeam Visual Installer as a bootstrapper UI application.
What I would like to do is set some variables inside the Custom Actions that my MSI is running, and I have figured out how to do that. I can see in my logs that the variables are being set.
My problem is I hoped that I would be able to read these variable and display them on the last page of my bootstrapper UI. Out here the variables still show as empty strings.
If you are familiar with Xeam, I am trying to access them like this:
MyProp = Bootstrapper.Engine.StringVariables["MY_PROP"];
Similar to the way you read and set properties during the initial bootstrapper workflow, before everything is sent to the MSI.
Has anyone else tried to do this. Should it be possible or are there any other solutions you can suggest?
This is apparently not possible. The solution is to use the registry instead.
I have been asked to add a function to an existing WiX package.
Specifically, I need to run a small c# application and return a single int back to WiX to conditionally control further actions.
I can see from ExePackage help that there is an ExitCode, but this is an enumeration of success, error, scheduleReboot or forceReboot.
I have googled quite a bit and I am wondering if I am missing the point. I can probably implement the C# process internally within WiX to get the user to provide the information I need, but the existing package already has custom ExePackages written in C# with a particular style, so I'd like to stay with that if I can. (The existing packages don't return any needed values)
Can I do this, or do I need to try and operate entirely within WiX?
For reference, one of the existing packages looks like this:
<ExePackage
SourceFile="..."
DisplayName="License Key"
InstallSize="0"
Permanent="yes"
InstallCommand="/ignoreIfLicensed"
RepairCommand="/ignore"
UninstallCommand="/ignore"
/>
The reference to <ExePackage ...> implies you want the condition to operate in a WIX bundle. In this scenario I think your options are limited and you can only map the return value of an ExePackage to global behaviour like forceReboot.
Do you have any <MsiPackage...> references? If you have, you could move the conditional behaviour inside each <MsiPackage...> using a Custom Action to call the exe and set a property. The property can then be used as a condition in each <component...> you want to conditionally install. See Using a WiX custom action to set a property's value for more information on custom actions setting properties.
I have a WiX bootstrapper theme xml file, and I want to permanently disable a control. I have tried to set HexStyle to the value of WS_DISABLED (link). However the control is still enabled. Anyone knows if I can use HexStyle or know of another way of having a control permanently disabled. I use the WixStandardBootstrapperApplication.RtfLicense BootstrapperApplication.
The possible solution is to find Id of this control and then create Variable with postfix "State". I hope it should work:
<Variable Name="EulaRicheditState" Type="string" Value="disable" />
I am writing an installer using wix. For silent installation using msiexec, i would like to provide few parameters from the commandline which i want to set to wix properties.
These properties I am using to enable/disable few features.
Can anyone please tell me how to read those command line properties passed to msiexec.
Using C++ Custom Action we read using MsiGetProperty
Thanks a lot..
Best Regards,
Marc
To make the property available from the command line you should define it using an upper case name. I often use a launch condition to check the properties have been passed on the command line:
<Property Id="PROPNAME" Admin="yes" />
<Condition Message="Public Property PROPNAME not passed">Installed or PROPNAME</Condition>
The Installed variable only checks for the property value on install rather than uninstall.
The command line for msiexec looks like this:
msiexec -i <msiname.msi> PROPNAME="PROPVALUE"
You should also look into the ADDLOCAL property. You can probably simplify your problem with a command line like:
msiexec /i product.msi ADDLOCAL=FEATURE1,FEATURE2,FEATURE4,FEATURE5
A Feature element can use one or more Condition elements as children. A feature condition can use installer properties directly in their formatted form, for example:
[PROPERTY_NAME] = "value"
Each feature Condition element must use a Level attribute. In your case it can be 0 so the feature is not installed when the condition is met. Basically, you will set a condition for skipping the feature.