What I believe to be a common occurrence is for Install4j to be used to generate both an installer as well as an uninstaller. From what I've seen, the installer can be used to reinstall/reconfigure the installed application.
On Microsoft Windows, the uninstaller gets registered under the Programs and Features > Uninstall or change a program item in the Control Panel. Is it possible for that uninstaller to be used to 'change' the installed application, rather than uninstall it? For some users of Windows, this might seem more natural than running the installer again, I suspect.
As of 10.0, install4j does not offer such a feature. You can add additional installer applications to run additional actions, but the "Install files" action can only be run in the installer.
Related
Install4J stores a registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\ej-technologies\allinstdirs* in windows when running an installer. Presumably it does something similar on Linux and MAC.
Is there a way to prevent this, and all other other permanent OS parameters, with a command line option? We run integration tests that actually run the installer and run then the application, but this then pollutes our registries, getting in the way of doing manual installations of the same application on our development machines.
As of 6.1, there no way to prevent this. I have added this to our issue tracker.
Few machines have 'MyApp.exe' installed using ClickOnce. And I have created a new MSI Windows Installer for 'MyApp.exe' using MS Visual Studio 2013 Setup and Deployment. I have a requirement that when my new MSI Installer runs it has to automatically remove/uninstall all previous 'MyApp.exe' (installed using ClickOnce) and install the new exe. Installer has to do it as part of its installation process.
Is this even possible? ClickOnce doesn't make any registry entries, so how can I get the Upgrade codes/Product codes which I can feed to Windows Installed 'Upgrade Paths' to upgrade it. ClickOnce is per user installation, but Windows Installer is not.
Is it even possible for Windows Installer to uninstall ClickOnce installed application ?
Any help is greatly appreciated. Thanks
ClickOnce is a per-user deployment experience and MSI is usually a per-machine experience. Per machine can't clean up other people's profiles. The only way I know is to do an active setup trick to run a program for each user who logs on and then execute a script to do cleanup. Either that or put first-run code in the applicaton itself to do the same.
I have a WinForm Application done in Visual Studio 2012, Framework 4.5. I made the Setup Project with InstallShield. I need to install this App on PC that may not have Framework 4.5 installed, so I add Framework 4.5 as a PreRequisite. So far So good.
What I want is to Install the PreRequisite automatically, without asking my clients when they Runs the Setup.
Is that Possible?
Thanks
Edit your PRQ to always install .net45 with no input. Here is a .net40 PRQ we use locally.
/passive has it show a progress bar, but you could just as easily do /q (no UI at all). The only problem would be a very long startup delay to your install which the user would probably interpret as "something is wrong" so I'd recommend keeping /passive.
InstallShield doesn't support this feature. The closest is to make the prerequisite mandatory. Another possibility would be to associate the PRQ to a feature to make it a "feature prereq" instead of a "setup prereq". This would cause Setup.exe to go right into your MSI and then defer the installation until after user interview.
I am currently using the Visual Studio 2010 Setup Project to deploy my application to an MSI installer file, which includes a Windows Service and a Windows Forms application. But I am disappointed with the performance and compatibility of this form of packaging.
My application is compatible with Windows XP and upwards, but several older XP user-testing boxes simply don't have the right version of the Windows Installer or the necessary service pack installed. (Un)installation can take dreadfully long for a program under 1MB in size and many systems do not support it. InstallState errors can crop up and ruin the (un)installation if the service has been deleted or already installed, or if any program files are missing (for uninstall).
What I need from an (un)installer:
Manage .NET dependencies.
Copy/remove my application files to a folder.
Add/remove menu and shortcuts to the desktop and Start menu.
(Un)install a Windows service, though I can also do this from my application. The stop and uninstall part is important.
Run my application when it's done.
This question's answers recommend NSIS (which I have used with good results) and WiX. Ironically there is no easy link to simple installer for WiX on their website.
Am I missing something with VS2010's setup project? It is optimized for speed, but it's just too slow.
You should run the installer/uninstaller explicitly with
msiexec /x thefile.msi /l*v thefile.log
(/i for install). Then inspect the log file; it will have time stamps telling you what action took what amount of time. Of course, the logging will affect that, but you should get an idea what makes it take so long.
I'm trying to access the TargetPlatform property value (which you can set in a Deployment project) from the condition within a "Launch Condition".
Basically I'm trying to tell the application not to install itself as a 32bit app if a 64bit version of Office is installed on that computer. Therefore I need to somehow get the application's bitness and put it in a launch condition.
I can get the bitness of Office from the registry, but I don't know how to access the TargetPlatform from the installer.
Thanks!
Here are two link:
Deploy1
Deploy2
From the above link you can deduce that you can't target both platforms from a MSI installer. You will need to have two installers. Depending on how the installer is built, x86 or x64, will depend the way the installer interprets some constants that tell where to isntall the files - Program Files, or Program Files (x86).
You can't change the TargetPlatform of the installer at runtime.
What you can do maybe is to have two installers packed into a third one and based on the Office version installed that you say you can obtain run either sub-installer x86 or sub-installer x64, that will actually install the application files.
If MSI installer is not the outmost requirement I would go for NSIS. If not at least package the to MSI installers into an NSIS one. It is incredibly easy. NSIS is way cooler than MSI, talking from experience.
I've read this question a few times now and I'm not 100% certain I understand what you are trying to do. Do you have a 32bit application and you only want to install if they have 32bit Office (2010 I assume) installed? Do you also have a 64bit version that you want to install if 64bit office is installed?
I'm not sure why you need to care about the TargetPlatform property because if you know that 64bit Office is installed you must by definition be a 64bit OS. If 32bit Office is installed you could possibly be a 64bit OS but does it really matter? You said you cared about the bitness of Office not Windows.
I would think, from what I've read, that if you have an AppSearch that pulls the bitness into a property that you could just use a LaunchCondition that uses that property along with "or Installed" ( to handle being able to uninstall your application if Office was uninstalled first ) and be just fine.
Add a custom action before the installation starts to perform the check. Use an Installer class to perform the custom action. You could use the OnBeforeInstall event to read the registry key and check the bitness as appropriate. Throwing an exception will cause the installation to abort, but there may be a cleaner way to do this.