So.. I've got this CA
<CustomAction Id="InstallSetProp" Property="CustomActionData" Value="<some other data that's formatted exactly the same> /webconftmploc="[WEBCONFIGTMPLOC]"" />
However, when this CA is called, a message box is shown saying "Error Getting Property" which is bogus since the property is correctly set and accessible later on. (And does nothing except mess up my attempts to fully automate installation) I'm running the .msi through a bootstrapper that switches /qr to help with this.
The message box error is not shown when /webconftmploc="[WEBCONFIGTMPLOC]" is removed, for the record [WEBCONFIGTMPLOC] is either an absolute file path or "Not Set" and I'm wondering if there's any special reason why this behaviour can occur.
However, I'm much more interested in any possible way to suppress or fix this action, of-course.
That CustomAction only sets a property. It is not possible for it to show an error message. If any of the properties were not defined they would just resolve to blank. Something else must be showing the error message.
However, it appears that you are trying to pass data to a deferred custom action due to your use of the specially named CustomActionData. That isn't quite the way to use CustomActionData though. Instead, the Property attribute should be set to the Id of the CustomAction that you want to pass data too. Say the custom action that uses that property value is something like:
<CustomAction Id='MyDeferredCustomAction' Execute='deferred' ... />
To pass it the string you are trying to send, you could write:
<CustomAction Id="InstallSetProp"
Property="MyDeferredCustomAction"
Value="<some other data that's formatted exactly the same> /webconftmploc="[WEBCONFIGTMPLOC]"" />
Notice that the second custom action is setting a property with the same name as the deferred custom action: MyDeferredCustomAction. The MyDeferredCustomAction can access the value <some other data that's formatted exactly the same> /webconftmploc="value_of_WEBCONFIGIMPLOC_goes_here" via the magical CustomActionData property. You can read more about that here: http://msdn.microsoft.com/en-US/library/2w2fhwzz(v=VS.80).aspx
Related
I am trying to install a msi file using msiexec on Windows. This msi can be installed either into the default ProgramFiles dir or a custom dir specified in the msiexec command.
For example when the custom dir is specified, the command looks like this:
msiexec /i installer_name.msi CUSTOM_DIR="C:\TEST" ALLUSERS=1
When CUSTOM_DIR is not specified then the command is
msiexec /i installer_name.msi ALLUSERS=1
For this to work, I am changing a Wix file and creating Custom Action and Custom Action Id.
When CUSTOM_DIR is passed by the installer, then
<Custom Action='InstallAppCustom' Before='InstallFinalize'>VersionNT64 and (CUSTOM_DIR) and (ALLUSERS=1)</Custom>
and when the CUSTOM_DIR is not passed then
<Custom Action='InstallApp' Before='InstallFinalize'>VersionNT64 and (Not CUSTOM_DIR) and (ALLUSERS=1)</Custom>
My questions are:
Is this the right way to check whether CUSTOM_DIR is passed or not? or any other right way to check it?
The issue here is that, irrespective of whether CUSTOM_DIR is passed or not, InstallAppCustom gets executed in the InstallExecuteSequence.
InstallAppCustom is getting executed everytime because CUSTOM_DIR will be always set. It must have initialized to some default value using Directory table. So, even if you didn't pass parameter, CUSTOM_DIR value will be set.
I understand why you want to check if parameter is passed from command-line but what if user changes CUSTOM_DIR value from UI? If it's not exposed to UI, then it's fine.
So, to check whether a property is passed from command-line, you need set property custom action which should be scheduled as very first action of InstallExecuteSequence, UISequence. Set property action will set CMD_CUSTOM_DIR property and its value would be [CUSTOM_DIR]. This should have condition of CUSTOM_DIR as at this point of installation time, default value of CUSTOM_DIR is not set. So, CMD_CUSTOM_DIR will always have cmdline value if passed and same can be used later on in other custom action conditions.
You can check the log msiexec /i yourmsi /l*v setup.log. There all cmd parameters and property changes and values are shown.
The above answer by Vivek helped me to solve the issue I had.
So I implemented something like:
<Property Id="DllPath32" Value="[ProgramFilesFolder]\App Name\dependencies"/>
<Property Id="DllPath64" Value="[ProgramFiles64Folder]\App Name\dependencies"/>
<!--CustomAction Id='SetDllPath64' Property='DllPath64' Value='[ProgramFiles64Folder]\\App Name' Return='check' /-->
<!--CustomAction Id='SetDllPath32' Property='DllPath32' Value='[ProgramFilesFolder]\\App Name' Return='check' /-->
<!--Custom Action='SetDllPath64' After='AppSearch'>VersionNT64</Custom-->
<!--Custom Action='SetDllPath32' After='AppSearch'>Not VersionNT64</Custom-->
The installation of the app worked as expected. Only issue is that, while uninstalling the app, the ProgramFiles64Folder is not changing to C:\Program Files.
I have defined the object store as following:
<objectstore:config name="objectStore" objectStore-ref="_defaultUserObjectStore"/>
And am trying to modify the watermark variable defined by name "lastmodified" in object store via a flow which call
<objectstore:store key="lastmodified" value-ref="#[payload.lastmodified]" overwrite="true" config-ref="objectStore" doc:name="Default User Object Store"/>
Note: payload.lastmodified has appropriate value of "2016-06-29T15:08:45.000Z" in it.
I am not seeing any error on console but when the next time the Poll executes it doesn't read the updated value of the watermark.
Any pointer would be surely helpful.
Thanks.
Instead of the method used above, try using poll-watermarking. Can set you update expression in poll-watermarking and if needed, can use object store also.
I fixed it by making changing the object store config to: <objectstore:config name="objectStore" partition="mule.watermark" doc:name="ObjectStore: Connector"/>
I have the following within the Product Tag:
<Property Id="LICENSEKEY" Admin="yes" Hidden="no">
<RegistrySearch Id="RememberLicenseKey" Root="HKLM" Key="SOFTWARE\MyApp\key1\Settings" Name="LICENSEKEY" Type="raw"></RegistrySearch>
</Property>
<Condition Message="License key is required to proceed">LICENSEKEY AND NOT Installed</Condition>
What I want to do is pass the License key as a command line argument to msiexec, and then set it in the registry. If the key is not passed I want to cancel the installation. Therefore, this check only needs to be run at install time. However, the condition that I have added causes a popup both at install and uninstall time. Can't seem to figure out what I am doing wrong.
EDIT:
I tested with the following condition and it seems to show the message both on install and uninstall:
<Condition Message="License key is required to proceed">NOT Installed</Condition>
The Message for a Condition element will be displayed when the condition evaluates to false, meaning the condition was not met.
This is noted in the Message attribute description in the WiX Condition documentation:
Set the value to the text to display when the condition fails and the installation must be terminated.
To resolve this issue, the logical operators in the Condition just need to be changed to LICENSEKEY OR Installed
This is a late answer, but, hopefully, this will help any future visitors that find this question.
You may need to clarify your requirement. That WiX source does a search for the key, so does it need to be passed on command line or you'll cancel the install (as your post says), or can it be used if it's found in the registry by that registry search? Currently it appears that your registry search is overwriting anything you pass on the command line, including setting it to null, so check that with a verbose log.
Also, all the launch condition examples I've seen or used have a CDATA around the text of the actual condition - that may be part of the problem.
I'll assume you allow the key on the command line or in the registry. So your registry search should be for another property name, let's call it REGKEY, so it doesn't set your passed LICENSEKEY to null. Then you have a set property (type 51) custom action immediately after the search that sets LICENSEKEY to REGKEY with a condition of -Not LICENSEKEY- so it will set LICENSEKEY to REGKEY only if LICENSEKEY was not passed on the command line. So if you pass it on the command line it will be used, otherwise the registry one will be used. At that point, a condition of LICENSEKEY should work ok as a launch condition. Internally, the AppSearch that finds the registry item is typically immediately followed by the launch condition check in a WiX MSI, so you need to set LICENSEKEY before the launch condition check.
I'm having problem with routing a message of binary file to a running instance of an Orchestration using correlation of context property: ReceivedFileName. The correlation is initialized using a send with dummy file where in the Orchestration sets the ReceivedFileName context property of the message and the property gets promoted. After that routing fails of the message being received (as XmlDocument) and I can see that the ReveivedFileName context property of that message has not been promoted should it be like that? I cant figure out any way to get it promoted so I just want to make sure it should be like this.
The file names are identical but I noticed that the ReceivedFileName property of the send message doesn't have the path whereas the received message has path + file name. I have tried to add the path to the send message(sounds strange though, read it some where) but it doesn't change the outcome.
While you can set Context Proerties in an Orchestration, they are not Promoted.
You have to use the Correlation Technique described here to have the Properties Promoted when they hit the MessageBox: http://blogs.biztalk360.com/property-promotion-inside-orchestration/
Basically, you Initialize a Correlation Set based on the Properties you need Promoted.
As Ben Runchey pointed out in a comment above one have to resort to a custom pipeline and promote the FILE.ReceivedFileName there by calling:
messag.Context.Promote("ReceivedFileName", "http://schemas.microsoft.com/BizTalk/2003/file-properties", receivedFileName);
I also removed the path from FILE.ReceivedFileName to only have the filename by calling the inmsg.Context.Read("ReceivedFileName", "http://schemas.microsoft.com/BizTalk/2003/file-properties")
and altered the value and wrote it back by calling:
inmsg.Context.Write("ReceivedFileName", "http://schemas.microsoft.com/BizTalk/2003/file-properties", receivedFileName);
I have one custom action that is executed all the time (doesn't have any condition).
This custom action is "deferred" and get correctly the value on fresh install or upgrade, but in repair mode the value passed is empty.
In setup log the value is shown with correctly, but in custom action the value is ''.
Is correct that in repair the value to be always null?