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.
Related
In [Components] I have two components (say A and B) defined exclusive. In fact the two components are not really components but two versions of the application configuration the user must choose from.
Assume the user has installed my application with component A chosen. If the user installs an update of my application this time choosing component B a warning box pops up that says
Setup has detected that the following components are already installed on your
....
Deselecting these components will not uninstall them.
Would you like to continue anyway?
Is there any way to suppress this warning message since it is in my case rather confusing to the user (since he knows that component A and B are just different versions of the application configuration)?
Am I misusing the wizard component selection page? If yes what else should I use to allow the user to select version A or B for his application configuration?
First, yes, you are possibly misusing the components. Would not a setup type be more appropriate?
Anyway, you can use the disablenouninstallwarning flag:
Instructs Setup not to warn the user that this component will not be uninstalled after he/she deselected this component when it's already installed on his/her machine.
Depending on the complexity of your components, you can try to use the [InstallDelete] section and this flag to automatically 'uninstall' deselected components.
I have a uCommerce package installed for my sitecore. The problem exists when you start editing template items under sitecore/templates/User Defined/uCommerce definitions/. When you restart IIS or recycle application pool (apparently this happens after solution rebuild) the template items reset their values to the fixed one. What could be causing the problem? Is there any cache mechanism which could be causing this?
update: have checked the sitecore database, the field values are being saved and stored in database properly after iis reset/pool recycly, so there is pretty much confidence that it has to do something with caching
The UCommerce DataProvider (UCommerce.Sitecore.SitecoreDataProvider.DataProviderMasterDatabase) automatically adds the templates under sitecore/templates/User Defined/uCommerce definitions at start up so they will always be reset after each recycle.
First off, make sure that you are making your changes in the Master database and not the Web database. If that is not the issue, then try the following while logged into Sitecore as an administrator:
Go to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the Sitecore cache
Go to the Master database's content editor and look at your templates
Make any changes necessary, save and publish
Do your IIS restart / application pool recycle (the latter occurs on every build)
Go back to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the cache again (just a base-case)
Go back to the Master database's content editor and look at your templates again
If the issue occurs after trying those steps, then you should open a Sitecore support ticket and see what they say. You may also want to try making a clean install of Sitecore and trying to reproduce the issue there (Sitecore Support is likely to do this as well).
The problem was that the standard values template presentation layout I have been updating was the english version. However, there was another language version set and the layout for that version was different. When uCommerce is resetting the template on application pool recycle it doesn't take into the account the multilanguage support, so the last retrieved language version of that fieldvalue is used as reset template and that different language version with different layout was used. A partial workaround is to use the same layout for all the language versions.
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'm developing an installer for an application which includes a Windows Service. The service will need a username/password from the user in order to get information from our server, so I'd like to set that during install. We also need to store that info in the Services config file so it has to be encrypted.
So I'd like the installer to call the same .dll the service uses when it encrypts the credentials. I set up custom actions created through the custom action wizard. I set it to "Call a public method in a managed assembly" and picked "Installed with the product" as the Location. I'm able to pick the dll and the target function and set everything up through the wizard. The path it resolves to in the installer log looks correct...
But I'm getting the error:
Unable to load managed custom action assembly
So not sure what to do in order to get this working?
The second part of the question is, what happens if the end user doesn't have .NET 4 installed? I'm going to set the installer to install it... but will there be problems or will we need to force a reboot partway through the install process? If so I might just temporarily store things unencrypted and have the service encrypt them when it first runs... which at this point is probably the easy way, but it doesn't feel like the "correct" way. ;)
I created a setup file which is working awesome.
Now whenever I rebuild an application without changing anything but Package Code is changed and then while I am going to install this version then a dialog will come "Upgrade Dialog" which ask me for upgrade an application.
Now in this situation I want to display an additional dialog created by me.
I am using the Insatllshield 2012 BASIC MSI project type.
I solved this problem.
There are two properties exist in Installshield named "IS_MINOR_UPGRADE" and "IS_MAJOR_UPGRADE".
When there is a minor upgrade at that time IS_MINOR_UPGRADE will set to 1. And same for Major upgrade.
So using these properties, I can recognize the Upgrade mode.
Any time you change the package code but not the product code you are talking about a Minor Upgrade or possibly a Small Update if you don't change the ProductVersion. Either way, the only way to create a custom message like you ask is to write your own setup.exe / update.exe bootstrapper to detect the update scenario and display your confirmation UI.
There's nothing built into MSI or IS that allows you to easily change this.