I had an issue with concurrency installation of 2 applications.
Using install4j5 created two separate .exe files (ONE.exe and TWO.exe.)
After installing ONE.exe (Not running) if I installed TWO.exe, the ONE application is getting uninstalled.
But if I tried to install TOW.exe while ONE is running, it is allowing to install both applications.
Is there any way to make the concurrent install when the other application is not running?
Related
Let's say there is installshield project consisting of several releases using the same script. This project builds several installers, for example:
Releases:
App A - builds into AppA.exe installation file
App B - builds into AppB.exe installation file
The project also contains Major upgrade items for each of them:
MajorUpgradeA - triggers for upgrade code of App A
MajorUpgradeB - triggers for upgrade code of App B
Everything works fine if only one of the apps is installed. If user have both of the apps installed then upgrade works incorrectly. With both when user tries to upgrade AppA using AppA installer file, then both AppA and AppB are uninstalled. It should only uninstall AppA, install new version of AppA and ignore AppB when AppA installer is executed.
How to prevent such behaviour, assuming that the project cannot be split to two seperate ones for each of the apps? Doing it in several different ways failed so far:
Triggering silent uninstall from script instead of using Major Upgrade items does not work because there can be only one active msi at a time during execution stage. It could be running in UI stage but then silent install does not work because it ignores the UI execution.
Upgrade components do not have any condition parameters/settings where it would be possible to set it to run such upgrade only if currently running installation has specific product code.
I have created an application in C# that relies on a specific driver (a custom virtual hid driver based on VMulti).
Currently, I have everything working and I want to combine both the application and driver into one installation package. As of right now, my application part has a .exe file and a .dll file. My driver has an .inf and .sys file, hidkmdf.sys, and WdfCoInstaller01009.dll (this dll is from the WDK). I am not able to install the driver through the traditional method of right-clicking the inf and clicking install. Instead, I use devcon to install it (command is "install inffile.inf hardwareid")
I tried using InstallShield LE, but I am only able to install the application, not the driver. After doing some searching, I found people using DIFxAPP to create the installation framework for drivers, however, I am not sure if this can be integrated into InstallShield so that the driver is installed during the application installation process.
So my main question is: What is the best and simplest method for combining application and driver installation into one package (meaning the setup.exe will install both the driver and the application)?
I am very new to driver development and application deployment, so any suggestions are welcome.
Thank You
EDIT: It is preferred that the solution does not require any paid tools.
Acctually, exists a many ways to implement this which depends on your Windows Installers skills.
You didn't specify target OSes for your application, that's why can I give you some ways:
PnpUtil.exe internal Windows 7 utility (only for Windows 7)
DPInst.exe included to WDK
DifXAPI merge module.
You can install drivers with help of all these utils via Custom Actions.
NOTE: That your driver SHOULD BE signed, otherwise you will receive error during silent installation.
I want to use SqlLocalDB for my application. The application is deployed with WiX. Now, I am searching a way to install SqlLocalDB when my application is installed for the first time. How can I do that? Would it be enough to deploy some binaries with my application or do I have to install the whole SqlLocalDB.msi? - When installing of the whole msi is needed - how can I do this with WiX? - The goal is, that the result is a single msi-file which holds all what is needed for installing my application.
I'm not aware of a private deployment model for LocalDB. If WiX is your tool of choice, you'll need to use it's Burn bootstrapper feature to install LocalDB as a prerequisite. The result will be a single EXE that installs 2 MSI's.
Today I created installer using Cava Packager Perl. I can install the app using the installer that I have created. But the problem is in my system that app is running fine but in other system app is not running. That is its getting installed but app is not running.
Assuming that your platform is Windows and the version of windows on which you are running the application is equal to or greater than Windows XP, you can create a diagnostic version of your application that will give full detail of the startup and loading process on the failing machine.
In the Build Options tab of Cava Packager, check the following two options:
1.Package Diagnostic Executable with release
2.Allow Loader Verbose Output in Release Executables.
Create your installer package and install on the failing machine.
In the installed bin directory, assuming your executable is called 'myexecutable' you should run:
diagnostic myexecutable.exe
You should get full details of the loading process and where it fails.
There are two very common reasons for failure when deployed to another machine.
A module you are using is linked to a dll that Cava has failed to automatically bundle
You are trying to run on Windows 2000 - which isn't supported by Cava.
Note: I'm involved with Cava Packager development.
We have a large application that has been developed over 15 years and in installed in 200+ client locations. The application currently consists of an Access database and a bunch of executable and report files located on a network share. A Setup.EXE file is run on each client machine (dlls are installed on the client) and then the client machines run the executables directly from the network share. During our upgrade procedure the new executable and report files are copied to the network share and that way each client gets the update immediately.
Our current installation program is very old and, among other things, it doesn't handle x64 so we are in the process of moving to a new deployment tool. At the same time we are migrating client Access databases to SQL Server. I am having difficulty finding a deployment tool to do what we require. Specifically we need the install/upgrade file to do the following:
It must be able to be run from a client machine on a network and copy the new executable and report files to the network share. That share could be a Linux box or a dumb storage device.
Accept a password before running the installation
Allow the user to select the network share as the location to copy the executables
It must NOT add anything to the client machine from where the package is run (Add/Remove Programs, registry, etc.)
Connect to a SQL Server database and run a script
The install/upgrade must be contained in a single, standalone .msi or .exe file. (no dependencies on dlls or frameworks other than those that come with Windows XP)
The file must be able to be run in one simple step. It is the end user that runs the upgrade without our support and without involvement from IT.
It looks like the closest thing to what I need is WiX but the problem there is that whenever the .msi file is run from a client, the client machine thinks that a program is being installed so it allows the client machine to uninstall the product, which is not acceptable.
If the product were written today it would certainly be architected differently but it currently is what it is and we can’t change that. Any help here would be greatly appreciated!
WiX is just a toolset built on top of Windows Installer technology. It makes many things easier and simpler as well as hides lots of Windows Installer weird features... But, it is still limited by Windows Installer, its underlying technology.
Your list of requirements made me think that Windows Installer is not the right technology to choose. I would assume that you'll spend more time on workarounds, than on functional code... But I have no experience with other installation technologies, so I'll leave those recommendations to others.