I am trying to install three application by creating custom dialog .Within Custom dialog there are checkbox and Onclicking checkbox and thereafter doing next I want my application to do file transfer ,install the prerequiste based on which checkbox is checked .I want this to happen for all the three application.Please suggest how to do it and how can we give the condition to do so.
Assuming you're talking about a custom dialog for a Basic MSI, I would suggest the following:
Ensure each application in question is part of a separate feature. If you go with the original dialog set, this would potentially let the user select them by feature name, or you could hide them. These features should have meaningful names, along the lines of App1, App2, App3.
Ensure your three check boxes are associated with different properties, such as INSTALL_APP_1, INSTALL_APP_2, INSTALL_APP_3. I show public properties here out of habit, but since they will be used in the same sequence (on the same dialog box, even), it's okay to use private properties. And use suffixes more meaningful than 1, 2, 3.
Adding multiple control events to the Next or Install button on the dialog box you described. For each feature you want to control this way:
Add an AddLocal control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is checked (i.e. with a condition like INSTALL_APP_1
Add a Remove control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is not checked (i.e. with a condition like NOT INSTALL_APP_1.
If you are going to show this dialog box during maintenance, you should also initialize the values of the check box properties (INSTALL_APP_1, etc.) so that merely going past this dialog box doesn't change their installation state. You can use feature-state condition syntax (!App1, etc.) to do so in SetProperty custom actions scheduled just before showing the maintenance dialog (e.g. set property INSTALL_APP_1 to the value 1 with condition !App1=3).
If these features are shown in a feature selection control, be sure to update the properties accordingly. Do so on the Next button of that dialog using a combination of the feature state and feature action syntaxes. The property should be 1 if the feature is currently installed and not being removed, or is being installed; it should be set to empty ({}) otherwise.
This is a lot of steps, but together they help ensure the features will act as a user expects. If he does nothing to change their state, they should persist as previously set. If visible in both the feature selection control and via check boxes, they should act in sync.
As far as prerequisites, if you mean the InstallShield concept of prerequisites, this you can associate prerequisites with the features for those apps. If you just mean other components inside your MSI, those work perfectly well with the features defined in step 1 as well.
I am trying to create a run-time image using Platform Builder 5.0, I know how to make run-time images but I need specific modules and files to be inside the run-time image, I am basically trying to clone an original run-time image and I want to add some extra stuff such as drivers for an ethernet card that was incorrectly configured, by using viewbin I was able to obtain the following modules and files, if it is possible can someone tell me exactly what catalog items I should add because at the moment I am using trial and error and it is not working, the modules and files are as follows
Modules
nk.exe,GIISR.dll, isr16550.dll, coredll.dll, filesys.exe, gwes.exe, device.exe, devmgr.dll, regenum.dll, pm.dll, fatfsd.dll, diskcache.dll, fatutil.dll, shell.exe, shellcelog.dll, toolhelp.dll, cmd.exe, atapi.dll, udfs.dll, fsdmgr.dll, mspart.dll, ceddk.dll, ppp.dll, pppoe.dll, export.dll, iphlpapi.dll, mbridge.dll, winsock.dll, ws2.dll, wsinstl.dll, wspm.dll, nspm.dll, secur32.dll, ntlmssp.dll, credsvc.dll, credprov.dll, afd.dll, ndis.dll, dhcp.dll, tcpstk.dll, tapi.dll, unimodem.dll, netbios.dll, ping.exe, ipconfig.exe, ndisconfig.exe, route.exe, netstat.exe, tracert.exe, serial.dll, mmtimer.dll, ole32.dll, oleaut32.dll, services.exe, httpd.dll, telnetd.dll,PCIbus.dll, pcc_tipccard.dll, pcc_serv.dll, pcmcia.dll, kbdmouse.dll, com16550.dll, ssce20.dll, ssceca20.dll, e100ce.dll - this is the driver that I am replacing, micro.dll
Files
ceconfig.h, wince.nls, initobj.dat, boot.hv, default.hv, user.hv, cemgrc.exe, cetlkitl.dll, cetlstub.dll, tcpipc.dll,
tlcesrv.dll, httpd_default.htm, NTLMInit.exe, version.exe, HECImageInfo.exe-version.exe and HECImageInfo.exe are run from an app on the drive itself.
I have tried adding the above files and modules that were missing by using the project.bib files in the Parameter view, but still this does not help. I am using this system on a MSM586SEN board and there is problems with the ethernet not connecting to the computer.
You can't just go and add these modules and files into your own BIB files. It's unlikely to work, plus it's a bad idea as there's nothing telling the system to generate those files. Select what you need from the catalog, which will set the proper SYSGEN veriables. That, in turn, will build the proper pieces and include them into the OS.
If you want to "clone" what was in an image, but don't have the project file for it, then look in the \windows\ceconfig.h file of the running OS. It will list every SYSGEN set during the build process. You can then manually set them in your new project, or select the proper catalog items to set them (hover on a catalog item and it will tell you the SYSGEN it sets - alternately you might just manually edit your project file with a text editor and add them).
Once you have that, then you can add drivers, debug connectivity issues, etc.
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.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html
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.