I am modifying an existing WiX installer to handle updating an existing installation of one of our products. There are several values whose defaults are specified in properties. These properties are displayed to the user for editing and are then written to a custom configuration file by the existing installer.
My code needs to be smart enough to detect if it is doing a brand new install versus installing an older version. If it is doing a brand new install, it needs to set the properties to default values. But if it is doing an upgrade, the code needs to retrieve the valus of those properties from the existing configuration file and display those to the user.
From the reading I've done, it seems to me I need to use a type 51 custom action to set the properties. But how do I implement this custom action?
I'm thinking that I have to first define the custom action to put it in the custom action table, and then I need to stick a tag somewhere to call it. And then I need to define it.
How can I do this? What would some example code be?
After doing some more research into custom actions, I believe I've got all of this figured out. I added a <Binary> tag to the .wxs file to identify where the custom action resides. I then referenced the Binary tag's ID in the CustomAction. Finally, I added a Custom tag to the InstallExecuteSequence section that referenced the CustomAction tag by ID.
The final Custom tag mentioned above needs to go into the InstallUISequence section, not the InstallExecuteSequence section, as the custom action needs to be called before the dialog is displayed.
As for the implementation of the Custom Action itself, I added a new C# Custom Action library project to the solution. In there, I implemented a method, decorated with the [CustomAction] attribute. This method uses the values of properties stored in the Session object passed as a parameter to the method and determines the path of the current version's executable file. It then does the work needed to locate the values in the program's Configuration file that need to be preserved across versions and writes them to other properties for the upgrade script.
Example:
[CustomAction]
public static ActionResult SetProperty(Session session)
{
try
{
session.Log("Begin SetProperty action");
session["PROPERTY_NAME"] = "value"
}
catch (Exception exception)
{
session.Log("ERROR in custom action SetProperty {0}", exception.ToString());
return ActionResult.Failure;
}
return ActionResult.Success;
}
Read the following sections of WiX tutorial:
Extra Actions: gives an overview of how to add a Custom Action to MSI;
What's Not in the Book: provides an example how to implement a Custom Action in DLL.
Related
My custom Eclipse editor overrides createAction, where it registers an IAction with the editor. Then, in editorContextMenuAboutToShow I add this action to the menu.
Everything works fine, in that the action appears on the context menu within the editor; and I'm able to invoke the action from the menu itself.
Now, I'd like to add a key binding for this action. So far, I've added three extensions to my plugin.xml: a command, a binding, and a context. I can actually see the command/binding/context show up in the keys preference.
As for binding the command to my action, I've passed the command id declared in plugin.xml as the parameter to setActionDefinitionId after creating the action itself in createActions.
Needless to say, the key binding doesn't invoke the action - hence this question. What steps am I missing?
In a TextEditor-based editor, I had to touch these places in order to provide an action with a key binding:
define a command, key binding and scope (as you did)
set the actionDefinitionId to match the command id (as you did)
after creating the action in createActions(), I had to call setAction( myAction.getActionDefinitionId(), myAction );
set the scope in initializeKeyBindingScopes() with setKeyBindingScopes( new String[]{ "org.example.myScope" } );
Does that help?
How can I get a path to file being installed from a WiX custom action?
I'm creating a WIX Extension, which has a custom element which can be nested under <File> component like this:
<Component Id="FooComponent">
<File Id="filekey" Name="foo.txt">
<myextension:Stuff />
</File>
</Component>
The extension has its custom table which has a foreign key columns pointing to "Component" and "File" tables, and it is executed when a file's component is being installed/uninstalled (like the built-in IIS extension or SQL extension for example)
What I want to achieve is, in my deferred (sheduled) custom action, figure out the target path of the file the extension isbound to. I.e. basically in the differed custom action, I want to get value of [!filekey] (in terms of MSI formatted string). How can I go about that?
I have found a somewhat similar topic here
One of the solutions suggested was to use MsiFormatRecord from a custom action and pass that [#filekey] to that function. It resolves properly then.
I've found examples of using this approach in WiX sources, in gaming extension and NetFX extensions; they use code like this:
StrAllocFormatted(&pwzFormattedFile, L"[#%s]", pwzFileId);
WcaGetFormattedString(pwzFormattedFile, &pwzGamePath);
Here WcaGetFormattedString is basically a wrapper for MsiFormatRecord
Still unanswered, is this a right approach to the issue?
Basically you pass that [!filekey] to the deferred custom action in that format, using the CustomActionData indirect way of doing that. Then in your custom action you get the property value [CustomActionData] . This might help:
How to pass CustomActionData to a CustomAction using WiX?
To spell it out, if your type 51 custom action that is used to prepare CustomActionData has a Target of [!filekey] then when you retrieve the value of the CustomActionData property inside your custom action then it will contain the full path to the file, the entire path and filename. This demonstrably works, although it wouldn't be practical if you were doing this for many files.
is it possible to set a property in Deferred custom action.If so please suggest me the way ?
I had similar dilemma few weeks back. And this is what was told to me by seniors.
Deferred Custom action cannot directly modify installer properties.
But there is an workaround: you can use immediate custom action to set the property.Also you could use CustomActionData to store property value and then use it in C# or VB.net Custom Actions.
I think this Link might help you.
The intended behavior of each custom action must be documented for the Windows logo program.
In InstallShield, custom actions are documented using the ISCustomActionReference table.
I am now using WiX to create my installs, how should custom actions be documented using WiX?
There's no reason you can't do the same - you can create a custom table in the MSI file with WiX and add your docs there. The docs typically emphasize custom tables to be used as data for custom actions, so maybe they're harder to find. There's an example here of a custom table WiX element if you scroll down:
How Best to Define a Custom Action
DTF does not call the second action if the custom action assembly has more than one action. It always calls only the first action. As a workaround, I am using one action in one assembly. It works perfectly always.
Do you have any idea on this issue?
public class CustomActions
{
[CustomAction]
public static ActionResult CustomAction1(Session session)
{
[some code]
}
[CustomAction]
public static ActionResult CustomAction2(Session session)
{
[some code]
}
}
I've never seen this problem as I group custom actions together in a single assembly all the time. Each method will be exported as type 1 entry points and then you write a custom action for each exported function. Windows Installer calls the CA which calls the function which fires up the CLR and invokes the static method that the custom action points to.
Probably, it will be helpful for some searchers, especially for .Net novices: double check that class and static method of custom action entry is public!
It might seem an obvious thing, but still. When you define a custom actions in your wxs file, do you specify different values in "DllEntry" attribute? This attribute points out a method, which is actually your CA. If you copy/paste custom action definitions, you might just forget to change the DllEntry...