I am having a problem with using a deferred CustomAction where the parameter is passed as a file id reference in the style [#file.Product.exe.config]:
<Component Id="comp.Product.exe.config"
Guid="{966DA007-E3F0-4BFE-94ED-63A66F82CA58}"
Win64="$(var.Win64)">
<File Id="file.Product.exe.config"
Name="Product.exe.config"
Source="$(var.SourcePath)\Product.exe.config"
KeyPath="yes" />
</Component>
Then I have a property called ConfigurationFile which is later on passed in to the deferred custom action like so:
<Property Id="ConfigurationFile"
Value="[#file.Product.exe.config]" />
I previously assigned the ConfigurationFile property Value="[APPLICATIONROOTDIRECTORY]\Product.exe.config" which worked just fine, but because we need to install the configuration to a different folder (the reason why this had to be done is irrelevant to this topic), I had to change it to resolve the location of the configuration file from the installer, using the [#file.Product.exe.config]
syntax.
When the custom action receives the parameter, it is still in the [#file.Product.exe.config]
format (that is, unresolved), and causing loads of problems. I was confused for quite a while because based on logging it seemed it should be working. It turns out that Session.Log(
) resolves this file reference, which resulted in the log "lying" to me about the actual content of the argument.
I have tried different approaches to "claning" this string, including session.Format()
which results in InvalidHandleException, using record (as stated below) and other ways with no luck.
using (Record formatRec = new Record(0))
{
formatRec.FormatString = p0;
return formatRec.GetString(0) // Or formatRec.ToString();
}
There are several custom actions provided in WiX that handles this convention. However, I have yet to find out how they do it. No luck as of yet when diving into the source code for these custom actions.
Arguments to the custom action is retrieved from Session.CustomActionData
.
Is there a nice way of handling this?