How do I to pass in a WiX variable defined in another file (without redefining it again)?
It seems like the standard way of defining a variable is this:
<?define Var1= "****" ?>
That's right, you can define some variables in this syntax. Then include them in a separate WiX include file, with the extension .wxi. (like a .h include file), for example MyWixDefines.wxi. Then in your other WiX file Fragments, include this file, like this:
<?include MyWixDefines.wxi ?>
And finally, in the other fragments, you reference the variable like this:
<Icon Id="myIcon" SourceFile="$(var.Var1)\images\someicon.ico" />
A reminder: The variable is resolved at WiX compile time. It's not dynamically available at install time.
Related
I've discovered how to access the parts within the MSI/Product tag. But my goal was to set the caption of the burn installer based on the Major/Minor version number.
This code below is the summary of what I tried to do, but this doesn't work (I think because I'm not within the Product tag).
Burn wxs:
<Wix>
<Bundle Version="!(bind.packageVersion.<packageName>)" >
<Variable Name="ProductVersionMajor" Value="!(bind.property.ProductVersion.Major)"/>
<Variable Name="ProductVersionMinor" Value="!(bind.property.ProductVersion.Minor)"/>
....
Theme.wxl:
<WixLocalization ...>
<String Id="Caption">[WixBundleName] [ProductVersionMajor].[ProductVersionMinor] Setup</String>
....
Is there some kind of work around where I can get this information at the bundle level without writing custom code?
This answer here was useful, but not quite what it appears I need; since I'm not within the WIX product tag for the inner MSI.
!(bind.property.ProductVersion.Major) is a bind variable when building an MSI, not a bundle. The available bind variables are documented at https://wixtoolset.org/documentation/manual/v3/overview/light.html. There is an open feature request for MsiPackage property bind variables at https://github.com/wixtoolset/issues/issues/4298. It would likely be additional work to get the ProductVersion.Whatever part working, so if you want that then you should add a comment to that issue.
In addition to #Sean's answer, if you are only interested in the full version and not in any breakdown of major/minor/build then the below example I have the caption in the localization WXL file can be defined as simple as:
<WixLocalization Culture="en-us" Language="1033" xmlns="http://schemas.microsoft.com/wix/2006/localization">
<String Id="Caption">[WixBundleName] Setup (v. [WixBundleVersion])</String>
...
and in my bundle.wxs file I have the following definition:
<Bundle Name="$(var.MyProductFullName)"
Version="!(bind.packageVersion.MyPackageId)"
Manufacturer="!(bind.packageManufacturer.MyPackageId)">
...
where the variable MyProductFullName is defined in my variables file under my package's installer project. So basically the [WixBundleName]
and [WixBundleVersion] are bound to the Bundle element's Name and Version attribute values, respectively.
I am trying to diplay label "Install" or "Uninstall" based on the action being performed by the wix burn installer. So far I have tried this:
<?define InstallStatus=[WixBundleAction]?>
<?if $(var.InstallStatus) = 5?>
<Variable Name="StatusLabel" Value="Install"/>
<?else ?>
<Variable Name="StatusLabel" Value="Uninstall"/>
<?endif ?>
But it always returns Uninstall. When I checked the log file, I got Initializing string variable 'StatusLabel' to value 'Uninstall'.
When I tried to print InstallStatus, it had no value (""). Seems like it is not set till then.
Is there any other way to achieve it?
<?define InstallStatus=[WixBundleAction]?> is preprocessor code that is evaluated at compile time but WixBundleAction is a Burn variable that isn't available until runtime. In v3.x you have to write code to set a Variable at runtime. In v4, there's a new SetVariable element implemented in #4948 that allows declaratively setting the variable like you're trying to do.
If you're using wixstdba, then you probably want to know about #4149 which added support for showing a different message for install vs uninstall.
In my bootstrapper Theme.xml I want to reference a path variable from a .wxs file.
In Bundle.wxs I reference certain variables using the $() syntax.
In my <BootstrapperApplicationRef> I use a ThemeFile.
From there I want to use the same variables (for example var.BundelVersionNumber). How can I achieve that?
Bundlex.wxs
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Bundle Name="MyApplication $(var.BundelVersionNumber) ($(var.Platform))"
I see that I can use some built-in burn variables, for example [WixBundleName ],:
http://wixtoolset.org/documentation/manual/v3/bundle/bundle_built_in_variables.html
You can declare a variable in your bundle and define the value based on a preprocessor variable.
<Variable Name="Platform" Value="$(var.Platform)"/>
Then you can use it in your theme.xml (or preferably your localized theme wxl ).
[Platform]
I am creating a WIX template for my projects to ensure a relatively standard layout.
I have defined a variable to reference the Main Application using <?define MainApp="MyApp"?> where MyApp is the name of the referenced project. I then use the MainApp variable to reference the project's properties in the .wxs and .wxi files.
However, I have an issue when referencing nested properties.
$var.($(var.MainApp).ProjectName) expands to "MyApp" without issue.
$var.($(var.MainApp).ProjectDir)Resources\Main.ico expands to $var.(MyApp.ProjectDir)Resources\Main.ico
$var.($(var.MainApp).TargetPath) expands to $var.(ConsoleApplication1.TargetPath)
etc...
My aim is to create a single definition for my main application, thus eliminating a search/replace, which I find clunky.
As you've found, nested preprocessor variables are not supported by the WiX toolset today.
In our WIX installer project, we need to generate a new file, let's call it FileB, based on a deployed file, called FileA in a managed custom action function. In another word, in the component declaration, I declare the FileA. While in a custom action (which happens at commit phase), I need to generate FileB based on FileA. After that, since FileA is no use anymore, I want to delete it in the same custom action.
And here comes the problem: with the default installation folder, which is Program Files, the normal user is not allowed to add file (generate FileB) into this folder in the custom action (I am not 100% sure I am right, but it is the case in my test. And if I install it in another folder, there is no problem at all). So I think I need to give permission of creating file. In order to do that, I add a CreateFolder element to the component which includs FileA. The whole component declaration is something like this:
<Component Id='COMPONENT_NAME' Guid='MY_GUID'>
<!--OTHER FILES IN THE COMPONENT-->
...
<CreateFolder Directory='INSTALLDIR'>
<Permission CreateFile='yes' User='Everyone' GenericAll='yes' Delete='yes'/>
</CreateFolder>
<File Id='MyFileA' Name='FileA' Source='PATH_TO_FILEA' KeyPath='no' >
<Permission GenericAll='yes' User='Everyone' Delete='yes'/>
</File>
</Component>
The component actually belongs to a component group, which resides in INSTALLDIR. The reason there is other files in the same component element is because I want another File to be the keypath, so that deleting FileA would not cause a problem of that. And now the generation of FileB is working fine. But later in the same custom action, I am experiencing the problem when deleting FileA. It just says that ": Access to the path 'DEPLOYMENT_PATH_TO_FILEA' is denied." I thought the problem lies in the FileA declaration, that's why I added the Delete='yes' in the Permission element under File, hoping to make it OK to delete it (although I am not sure whether this means in the installation it is possible to delete). But still I get this error. Can anyone tell me what I did wrong?
Another question is, I really don't know what is the purpose of those CreatFolder elements. For one thing: if the aim is to create the directory structure, I think the (nested)Directory elements already do that. And why to have such element under Component element when most of the time you probably want the directory structure to be separated with component structure(the components just use directory reference to refer to correct directory). Secondly, the default Directory property of CreateFolder is the parent Directory where the component resides in. But it is common that more than one components reside in the same directory, like what I have here: multiple components are in the same component group, whose directory element references to INSTALLDIR. So only one of these components has the CreateFolder element, whose Directory property in my case is the parent directory of all those components. It is really hard to understand this structure. I guess I have some misunderstanding of the CreateFolder element. Can someone enlighten me to usage of CreateFolder? Thanks!
Thanks!
A number of issues to address here. First, you should know that Commit phase custom actions don't execute if rollback is disabled. You should really have an deferred and rollback custom action.
Second, you can't tell MSI to install a file and then go delete it. That's counterproductive and just causes servicing issues down the road. A better solution ( I'm assuming you are using a WiX DTF managed custom action ) is to include FileA as a content item in the custom action project. This will cause the file to exist in the current (temp) directory of the custom action while it execute. You can then generate fileb. For rollback, you can delete fileb.
You'll also need to author a RemoveFile element to teach MSI to delete the file on uninstall. Otherwise it won't since MSI doesn't know anything about fileb created by your out of process custom action.
Otherwise it'd be useful to know what the contents of fileb are. It would be easier to implement if this was an xml file that could be installed as fileb and then transformed using the xml wix extension.