I'm making use of install4j's auto-update feature for an application I'm working on. I was wondering how exactly it determines whether an update is required?
I'm not sure whether it's based purely on the application version number being compared to the newProperty value in the relevant entry in updates.xml. Or, does the Application ID (in the installer configuration screen) come into play somewhere?
The update detection logic is customizable.
Look at your updater installer application on the Installer->Screens & Actions tab and locate the action named "Update descriptor entry". That action is just a "Set a variable" action with a script of
((UpdateDescriptor)context.getVariable("updateDescriptor")).getPossibleUpdateEntry()
The method UpdateDescriptor#getPossibleUpdateEntry() compares the version number of the installed application to the version numbers in the downloaded updates.xml file. More precisely, it locates the entry in updates.xml for the media file ID matching the media file ID of the installer that was used to install the current installation and uses the version number of that entry.
You can replace this logic with your own logic, for example using custom attributes in the updates.xml file that were configured on the Installer->Auto-Update Options tab.
Related
I am using WiX and want to know if we can disable a control in a built-in dialog. My requirement is to disable the "Browse" button in the "CustomizeDlg".
This became too long for a comment. I might "evolve" it as an answer if we get more information about your scenario. Just a couple of heads-ups for you.
If you are trying to prevent the setup from being installed to a non-standard path, then you should account for the fact that the installation directory can be set at the msiexec.exe command line when the setup is installed in silent mode. Sample (untested by me - first thing I found :-) ).
I suppose a custom action could be used to abort the setup if it is installed in silent mode to a non-standard path? An immediate mode custom action before InstallInitialize somewhere I guess, but after costing actions (CostInitialize, CostFinalize, FileCost, InstallValidate, etc...) - but frankly, why do this? Perhaps you could illuminate your use-case?
Oh, and please don't leave the standard action RemoveExistingProducts to run before your custom action (in the InstallExecuteSequence). This would remove the existing, related installation on the box (if any) and then abort the major upgrade operation leaving no install left on the box.
And don't add your custom action to the user interface sequence - there is no need. This sequence is entirely skipped in silent installation mode, and if there is no way to set a custom path in the GUI, it can't be changed there anyway (and the InstallExecuteSequence's custom action would catch any changes should they be set anyway - it will do).
Per this thread which discusses how to enable the button, what you need to do is the reverse: ensure your Feature elements do not specify a ConfigurableDirectory, or that it is not public by using some lowercase letters in the identifier.
I am a bit of a beginner at InstallShield (in the sense that this is the first time I've used it!).
I have some code that I am packaging up in a .net DLL to check for the existence of anti-virus. The installer I am attempting to create must check for anti-virus (by calling a custom action using my DLL?) and cancel the install if none has been found.
The way I seen it working, was the user would see a dialog that is informational ("about to check for anti-virus"), the user would press "Next" it would call the custom action and then show a success screen with a "Next" button, or a failure screen with "Finish" button.
Is this sort of thing possible with InstallShield? Are there any good tutorials out there for doing this sort of thing?
Do you really need a custom action? Do you have more detailed requirements with regards to what products and versions you are looking for?
InstallShield / Windows Installer has a built in search pattern that can look for registry entries, files, et al.
If you really do need a custom action, how long do you expect the execution to take? If it's only a couple seconds, just schedule it to run after AppSearch. You don't need a UI to say "now doing blah" just do it.
Since you want to do this in .NET, you need to look at Windows Installer XML (WiX) Deployment Tools Foundation (DTF). You can use this to author/compile custom action DLL's that InstallShield can then consume. Generally the custom action should do it's search and then set a property based on it's result. Then use that property in evaluating whatever business rule you are trying to implement.
I created a multi tiered .net application which includes the Client and the Server projects. I want to create setup for it so that during installation, the user may choose to install the Server or the Client (by selecting appropriate radio button). I created an interface for the selection but it always installs both the Server and the Client no matter which option I select. How can I choose to install only Server or Client based on the selection?? Thanks.
You need to set the Condition property on the appropriate output files based on the radio button selections. Here is an article that shows step-by-step instructions:
http://msdn.microsoft.com/en-us/library/9x23561f(VS.80).aspx
It's quite simple. Assume that you have 'ServerInstall' and 'ClientInstall' (let those be simplified terms for file systems etc. corresponding to each version you want to install). Now, having a RadioButton(2) dialog box in your installation, you gain access to a condition (in the example - BUTTON2), which has to be set in each file to value 1 or 2 depending whether the file is specific for client or server.
Here is my scenario. I am using Quicktest Pro (VB) to create an ActiveX object from a Labview VI that I built into an executable. In the build specs of the VI I have enabled ActiveX server option (ActiveX server name: "MyLabviewProgram") and in the VI Tools>Options>VI Server: Configuration the ActiveX box is checked.
So in QTP my code is:
Set IvApp = CreateObject("MyLabviewProgram.Application")
Set Vi = IvApp.getVIReference("MyLabviewVI.vi")
Vi.Call ParamNames, ParamVals
Upon running this I get a Run Error on the first line:
ActiveX component can't create object: 'MyLabviewProgram.Application'
I am having trouble figuring out why it errors. From National Instruments website they have a step in on one of their community pages about "LabVIEW Executable Used as ActiveX Server". The step is after building the EXE, 5. Run the EXE at least once on the target to activate the .TLB file. I've run the executable but not sure what they mean by on the target.
Does anyone have a suggestion on what I need to do to get this working?
Your description sounds like you correctly created a vi .exe. "On the Target" probably means "On the Target PC". The EXE adds all COM registration entries to the Windows registry each time it is executed.
It sounds like you haven't verified the COM registration entries are present in the registry yet. That's the first debugging step.
Run regedit.exe and search for MyLabviewProgram.Application under the HKEY_CLASSES_ROOT sub-key. You should find an entry that contains a sub-key that contains a value that contains a GUID (a large hexadecimal number).
That "class ID" GUID should be referenced under the HKCR/CLSID key. That reference should contain a LocalServer32 sub-key with the default value pointing to your application's .EXE filepath with the /Automation argument appended.
It seems likely that one of these steps will fail. I can't say exactly which one without more information.
1.
I am using WiX for creating installer and would like to implement the following behaviour:
If a user launches msi installer for the product and the product already installed, then wizard works similar to pure (first time) installation with exception of some things (e.g. license aggrement screen is omitted). The wizard should allow for example to change installation folder, select whether to place desktop shortcut,...
I tried to do:
<Publish Event="ReinstallMode" Value="amus"><![CDATA[INSTALL_MODE = "Change"]]></Publish>
<Publish Event="Reinstall" Value="ALL"><![CDATA[INSTALL_MODE = "Change"]]></Publish>
But after installation completes: the product is in the same folder, where it was installed first time; desktop icon in the same state as it was after first time install.
MSDN says: "Do not attempt to change the target directory path if some components that use the path are already installed for the current user or for a different user".
Is there a way to re-install in another forlder and add/remove desktop icon in re-install?
2.
Is this normal to use the same KeyPath for some components?
For example the same registry values for DeskTop and Programs menu shortcuts? MSDN says: "Two components cannot share the same key path value". But compiling and verifying goes OK. And I did not discover problems using the same keypaths.
I'm not sure I understood your requirements correctly, but it seems the Major Upgrades cover the functionality you need.
Take a look at this ancient ;-), but still valuable blog entry by Rob Mensching. The KeyPath concept is clearly explained on an example there.
Hope this helps.