I'm looking for a way to extract the launchers of installers created by install4j (mainly Windows installers).
My goal is to send these launchers for inclusion on the white list of antivirus sites.
I tried to use the Executable Processing option, but this operation takes place before the signing of the launchers and the silent mode makes too many changes in the machine.
It's not possible to extract files from the executable without running the installer.
At build time, you can pass the
--preserve
argument to the compiler, or check the "Do no delete temporary directory" check box in the "Build" step of the installer, then the staging directory with the launchers in the %TEMP% directory will not be deleted after the compilation finishes.
Related
is there a way to install more than one .msi and .exe file parallelly using PowerShell.
let's say we have all the installers in one directory
I found a script to install all the files sequentially.
Install all the files from a given folder with Powershell
Previous Answer: Two MSI files can not run concurrently, the reason is explained in this short, old answer on serverfault.
Essence: In essence MSI installers run as a transaction and hence set a mutex to "lock" the system while it finishes installing. This is primarily in the interest of supporting rollback - which means you bring the system back to the original state if the installation fails for some reason. The lock also helps to ensure general reliability by facilitating proper debuggability and logging of failed installs and prevention of deadlocks and duplicate overwrites, etc...
Things you should know:
While the mutex lock is set, other MSI files can be launched to the GUI section, but they can not be kicked off to do the actual installation (system update). You will get an error message if you do so.
Note that legacy style installers (exe files) do not heed this lock and can be run while MSI files are running, but you should not do so. Run installers in sequence and check for errors for each one. The improved I/O of modern computers means installers run very quickly, just do them in sequence. There are some speed-tweeks for MSI installers.
Links:
Other installation In Progress Hanging my Wix Install
I have a Dell PC with Win7 64 using what I believe is the latest version of AutoHotKey.
I wrote an Installer App with AutoHotKey to create two directories with a number of sub directories then install an exe program and a number of data files into those directories. The App installs into the existing C:\Program Files and C:\Program Data directories.
The Installer App creates the sub directory C:\Program Files\DSOSort then installs the file DSOSort.exe. The installer App then creates the sub directory C:\Program Data\DSOSort and installs a number of additional sub directories with all the associated text data files.
I used the FileCreateDir and FileInstall instructions in the Installation App to create the directories and install the files.
Everything in the Installer App and in the exe program works as it should except that the exe will not make any changes to the text data files in the newly created C:\Program Data\DSOSort directory. I have to open the directory with Properties and allow Users to Write. Once that is done the exe will change data in the text data files correctly and all is well.
If I change the Installer App to create a directory C:\DSOSort then install all the sub directories and data files in there instead of into C:\Program Data\DSOSort the exe can write to the text file. I do not have to change any permissions with Properties.
I tried using the various copies of the C:\Program Data\DSOSort directory I found in C:\Documents and Settings and also in C:\Users. The exe can read them but no Write.
I only have this problem with newly installed directories and again as I said earlier it can be corrected with Properties.
The exe program was written for people with enough knowledge to run the Installation App but do not understand Properties or making changes to the directories.
I could just leave the data files in a C:\DSOSort directory but would prefer to put them in a C:\Program Data\DSOSort directory.
Is there a way for AutoHotKey to check the user permissions and changing them if necessary before installing the data files?
Is my PC behaving properly? Is it supposed to create directories without allowing Write to the files?
Some of these directories, like "Program Files", require admin privileges to modify. I believe that is why you're experiencing that. Have your app run as an admin and it should be fine. The setting for you EXE can be found in the properties.
The A_IsAdmin built-in variable returns whether the current user has admin rights.
I'm completely new to Microsoft installer and have installed advinst.msi, and I'm wondering how to use it.
I have to group Jboss where my Java application is deployed and postgres database and want to create an .exe file and deploy it to clients windows system.
Where the client can run the .exe file and start the application.
The Jboss package you can add a as a prerequisite. This will make Advanced Installer to install it when you install your application, see the link from above.
To deploy a database you have two options. Either you execute an SQL script that creates and populates it, as in this SQL scripts execution tutorial, or you deploy directly the binary files of your database, by placing them in the target folder from Files and Folders page, as you do with a normal file. The second option will make your installer to copy the files into the desired folder upon installation, so you database manager/explorer can access it.
To have all this bundled into a single executable you need to go to Media page and set the package output type to "Single setup EXE". From there you can also customize the EXE name, icon and output folder.
What would be the best way to deploy upgrades to a piece of software with the following requirements:
The upgrade:
Must be run from a client machine, not a server.
Must Show a dialog to select a network location and copy files to a share.
Must show a dialog to enter SQL Server connection information and the upgrade must connect to SQL Server to run an upgrade script.
Must not change anything on the client machine from which the upgrade is run. (Nothing in Add/Remove programs, registry, etc. I.e. no Windows Installer.)
Must not rely on any additional dlls or frameworks. The user must be able to download a single file and run it from Windows XP SP2 without having to install anything else.
Some things I have looked into:
Batch files (can’t show a dialog to allow the user to enter connection information)
OSQL (can’t show a dialog and can’t copy files)
WiX (runs on top of Windows Installer so it puts things on the client machine from which it is run)
Custom C#/VB app (requires .NET framework)
Winzip/WinRAR (can't show a dialog, can’t run SQL Scripts)
If you don't want to rely on any dlls and frameworks, you should make a native app, this can be, for example, custom winrar sfx (you can run additional scripts after extraction, this can be a batch that executes sqlcmd).
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi