Screenshot of custom action
edit: where should I mention the property as attribute? and how will the property created in MSM be exposed by the exe and how should it be set?
I am using an Basic MSI project to install a Merge Module, which internally invokes an .exe using custom action in differed mode. I would like to pass arguments to the custom action while invoking the exe. How can I pass arguments dynamically to the custom action?
You cannot do that directly. You're only hope is that the custom action uses public properties as input parameters and pass the updated value for those properties when you call the MSM.
Related
i have an ism which contains two chained msi.
curentlly, the installer in the end do the two chained msi as the last action and then finish.
can i add a custom action after the chained msi?
i want to do it after the chained msi done
thank you in advance!
You cannot add a custom action per-se. There are a few options I've used in the past, depending on your needs one of them may suit you:
If your installer always runs with UI, you can add a custom action at the end of the User Interface Sequence (after ExecuteAction). This will get executed only after all chained MSI packages were run.
If you don't need access to the MSI properties (or can read the data from the registry or somewhere), you can just create another basic MSI that does what you need, and chain it as the last MSI to run. MSI packages are executed in the order specified in 'Order' column of the ISChainPackage table.
InstallShield Support recommends this approach (there are several threads about it in their support forums).
Finally, if your custom action can be implemented using an MSI Transform, consider doing that. Transforms are applied after all chained MSI were run.
after creating an application pool in IIS(8.0) using Release Management 2013 Update 4, I need to customize the predefined action.
I would like to set Load User Profile in the advanced application pool settings true instead of false. I assumed I could use -loadUserProfile as an argument in Release Management.
Apparently the arguments are not similar to the parameter names in IIS. The release was rejected and the log file showed: ERROR: loaduserprofile : Unknown Option.
Release Management is using IISConfig.exe to execute the arguments. Even knowing that, I was unable to find a list of arguments or "Options" which can be used for the IISConfig.exe.
I would be glad to know how to solve that Problem. Not only in that specific case but in general.
Find the details of the IIS tool here:
https://msdn.microsoft.com/library/vs/alm/release/overview
Scroll to IIS Deployment Agent.
There does not seem to be any way to change the Load User Profile. You can write your own tool to accomplish that (and share it here :))
I am working with Liferay 6.0 on JBoss 5.1.1, Windows 8 is the OS. On server startup I always get the following error explaining the auto deploy directory can't be found:
ERROR [AutoDeployDir:90] Directory F:\liferay-portal-ee-6.0\deploy could not be created
This makes sense because I don't have an F: drive. However, I'm unable to configure it in the portal-ext.properties file as explained here. When I log into the Liferay control panel, and look under Portal Administration -> Portal Properties, I can see that the value I put in ext.properties is indeed displayed as the value for auto.deploy.deploy.dir. However, when the server starts up, it is using F:\liferay-portal-ee-6.0\deploy as the auto deploy directory and logging the error above. I have debugged the GlobalStartupAction class which initializes Liferay's auto deploy and I can see that it's calling PrefsPropsUtil.getString(String, String) to retrieve the value for the auto deploy directory and it's passing the value I set in portal-ext.properties as the second argument, according to the PrefsPropsUtil Java doc the second argument is a default value. When I dig down into the PrefsPropsUtil.getString call I can see that it's using an instance of PortalPreferencesLocalServiceImpl to retrieve a list of properties by companyId, ownerId and ownerType which are set to 0, 0 and 1 respectively. Since the PortalPreferencesLocalServiceImpl is "local" I'm assuming it's not going to a different machine to retrieve values. I've done extensive directory and file searching for references to auto.deploy.deploy.dir and values like F:\liferay-portal-ee-6.0 and I'm unable to fine where this property is getting set. Where is this value coming from and why isn't my override being used?
Since you are using Liferay 6.0, go to Control Panel-> Plugins Installation -> Install More Portlets -> Configuration.
In the configuration tab, you may see the Deploy directory set to be F:\liferay-portal-ee-6.0\deploy
This may be because either someone has modified the value from the control panel or you are using database dump from some other existing Liferay installation.
You can use auto.deploy.dest.dir property in portal-ext.properties to set auto deploy path.
i.e
auto.deploy.dest.dir=C:/../../autodeploy
HTH
I am running custom action that suppose to execute some function in provided dll.
this function connects to sql db and do some select with return, but i cannot see the return value.
How can i debug this function in dll, or check if it is really executed.
I've use C++ custom action DLLs, so I'm not entirely sure how a C# custom action DLL differs. However, I usually use the method Ondrej mentioned: logging to the MSI log file and/or message boxes that pause the custom action execution so I can attach to the process via Visual Studio.
Are you familiar with how that is done?
InstallShield has native SQL script handling for most of your needs. This will automatically give you a lot of logging in the MSI log file. However returning result sets is one thing it doesn't do.
The best thing to do is write your managed C# custom action using Windows Installer XML (WiX) Deployment Tools Foundation (DTF). This builds custom actions that appear as C++ custom actions to the Windows Installer and is fully compatible with InstallShield.
Inside of a DTF custom action you can use session.Log() to record useful debugging information in the Windows Installer log file. You can also attach a debugger to the custom action and step through it if you want. See the following for more information:
Deployment Tools Foundation (DTF) Managed Custom Actions
I am having a problem with a Wix installer, that covers three different feature sets (Client / Developer and Server).
When Client is selected the installer does not need to perform any of the actions with IIS that are defined in components that aren't included within this feature.
On Installation I don't get a problem, as I have added a Custom Action
<!-- Only perform the IIS Configuration if we have installed the Admin Application-->
<Custom Action="SkipIISCA" Before="InstallValidate">
<![CDATA[COMPONENT_TYPE = 2]]>
</Custom>
Which is only run when the "Client" component type is being installed. The custom action sets the SKIPCONFIGUREIIS property to 1
The problem occurs when either a Repair on an uninstall is executed on the installer. It appears that IIS Configuration is being attempted when the product is being uninstalled or repaired, and the custom action does not seem be run to disable this behaviour.
Is there a good way to set the SKIPCONFIGUREIIS setting on uninstallation / repair based on a Registry Setting ?
Thanks.
Some of the properties set during an installation are stored in the hidden windows directory, c:\windows\installer - one per installation. In the log of your uninstall/repair session, you can see that cached file opened up and properties being set for the new uninstall/repair session. (Alternatively, you can find this temp file from the uninstall/repair log, and open it with Orca. In Orca, under "Property", it will show the values of any install properties saved).
Based on the above description, I bet that the property that the custom action is being set is not stored, but that the value of COMPONENT_TYPE is available (The same input that was used to set SKIPCONFIGUREIIS in the custom action).
If so, then just make the IIS configuration action be based on these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT SKIPCONFIGUREIIS ) OR (COMPONENT_TYPE = 2)</Custom>
If you don't want the ConfigureIIS to happen for any feature set during uninstall/repair, then just use these properties:
<Custom Action="Your_Configure_IIS_Action" Before="InstallFinalize">
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")</Custom>
Another thing to think about is if the original installer was at one level - e.g. a client, and the uninstall/repair is being done by someone at the server level. The component_type of the original install is stored. In that case, you might consider adding a check on how the component_type is determined (thru a dialog or some other attribute) during the uninstall/repair.