I have some installers like
JDK
Apache Tomcat
MySQL
MySQL GUI, etc.
I want to bundle all these installers together into a single .exe file, So that a single exe will in walk through all of the installers one by one. The result will (hopefully) make installation of many packages as painless as possible for the user.
MySQL installers were in .msi format. I converted them into .exe by using an MSI to exe converter.
I'm able to find many setup creators, but I don't think they'll do what I want. How can I bundle all of these packages together under a single installer? Is there a tool that I can use to do this?
I got some useful links http://en.wikipedia.org/wiki/List_of_installation_software , Refer this question
Related
GitHub recently released a container registry alongside their package registry. What is the difference? When would it be better to use one or the other? Do we need both?
Packages are generally simple: they are essentially an archive (i.e. zip file) that contains contents (code libraries, application executables, etc.) and a manifest file (json document, xml file, etc) that describes those contents with a package name and version number (at a minimum).
ie:- npm,pip and composer packages.
Container images are also simple, but they're more like an archive (i.e. a zip file) than a package.
ie:- nginx, redis etc
Verdict:- if some libs repetitively used in any project then we can create package and use in project .while for all project based dependencies we need to choose container to run this. Yes we need both.
After debating this with a Docker-using friend for a while I think I've found a satisfactory explanation:
Packages are for modules of code which are compiled together into an
Application.
Containers are for Applications which are compiled together into a
Server.
This is a bit confused by the fact that a Package can contain a standalone Applications, and Containers will often use package managers like Apt to install these applications. I feel like this is an abuse of package management due to a legacy where we didn't have Containers. Eventually I would expect most Applications will be delivered in Container form.
I am very new with electron application. I need some help with election installation.
I have an Electron desktop application and a windows service.
I can start and stop my pre installed services by using sudo-prompt package.
I am creating windows installer by using electron-winstaller package.
But I want to bundle my windows service along with my electron application. My requirement is when I install my electron package then it should install my service also, when I uninstall my package then that service should be uninstalled.
Please help me out. Any clue, Any suggestions will be appreciated.
If you think this should be achieved with something else then please do suggest me.
Electron's windows installer packager strikes me a specific case tool that would likely hit limitations in scenarios like this. I would use a general case tool instead such as the Free and Open Source Windows Installer XML Toolset aka WiX. I would also use with that another FOSS application called Industrial Strength Windows Installer XML aka IsWiX.
WiX allows you to describe and build MSI databases using an XML/XSD domain specific language. It supports MSBuild for easy integration with your CI/CD pipeline. IsWiX* is a set of project templates and graphical designers that provide an opinionated project structuring (scaffolding) and greatly speeds up the learning curve and implementation. For example, this installer you describe could be done without writing a single line of XML.
For more information see: https://github.com/iswix-llc/iswix-tutorials
The desktop-application and windows-service tutorials should** show you everything you need to know to author this installer. Basically follow the desktop-application all the way through and then skip to the final portion of the windows-service tutorial where you define the windows service.
I'm the maintainer of IsWiX
** This assumes your service exe is a proper Windows service that interfaces with the windows service control manager. If it's really just a console app that runs as a service you will need to include a program such as srvany.exe. This will require one line of hand crafted XML to extended the service definition in the registry with the proper command line value to be passed to your exe. An example can be found here: Wix installer to replace INSTSRV and SRVANY for user defined service installation
In the past I have used environment modules extensively in Unix based systems. The tool proved very usefull since we had many different projects each of them using a potentially different set of tools.
I am now however stuck with a windows machine and need to make the most of it. Does anybody know of a good alternative to environment modules for windows? I am basically looking for a tool that let's me manipulate the PATH (or $env:PATH in windows powershell) environment variable without having to touch it directly.
You can install environment modules on windows as well. The instructions are in the repository https://github.com/cea-hpc/modules/blob/master/INSTALL-win.txt
Basically you have to install active state tcl and copy the source files.
I use this and it works quite well.
Following MS' advice we have stripped most files from the DX installer contents for our D3D9 application, getting it down to 5Mb in total.
But now I;d like to package these files into a single installer, like the redistributable installers MS themselves provide... so it can be run as part of our application install process, with /silent switch, without manually having to unpackage the files and delete them.
Is there a simple, standard way to do this so that the packaged DXSetup.exe is run?
Or is all this too complex and we should just unpack the files, run DXSetup.exe and then delete the files after installation?
Its better to use the installers that MS provide, usually is what Apps do, if the problem is space you could always use web installer its 300kb but will require the user to have an internet connection.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en
On the other and if you're using DirectX SDK
there is a folder "redist"
and in it there are setup's of DX,
you can distribute them with your app,
and your Setup has to call the dxsetup.exe
I searched a lot, but all are guessed answers. Help me to find the exact answer.
An MSI is a Windows Installer database. Windows Installer (a service installed with Windows) uses this to install software on your system (i.e. copy files, set registry values, etc...).
A setup.exe may either be a bootstrapper or a non-msi installer. A non-msi installer will extract the installation resources from itself and manage their installation directly. A bootstrapper will contain an MSI instead of individual files. In this case, the setup.exe will call Windows Installer to install the MSI.
Some reasons you might want to use a setup.exe:
Windows Installer only allows one MSI to be installing at a time. This means that it is difficult to have an MSI install other MSIs (e.g. dependencies like the .NET framework or C++ runtime). Since a setup.exe is not an MSI, it can be used to install several MSIs in sequence.
You might want more precise control over how the installation is managed. An MSI has very specific rules about how it manages the installations, including installing, upgrading, and uninstalling. A setup.exe gives complete control over the software configuration process. This should only be done if you really need the extra control since it is a lot of work, and it can be tricky to get it right.
.msi files are windows installer files without the windows installer runtime, setup.exe can be any executable programm (probably one that installs stuff on your computer)
MSI is an installer file which installs your program on the executing system.
Setup.exe is an application (executable file) which has msi file(s) as its one of the resources.
Executing Setup.exe will in turn execute msi (the installer) which writes your application to the system.
Edit (as suggested in comment): Setup executable files don't necessarily have an MSI resource internally
MSI is basically an installer from Microsoft that is built into windows. It associates components with features and contains installation control information. It is not necessary that this file contains actual user required files i.e the application programs which user expects. MSI can contain another setup.exe inside it which the MSI wraps, which actually contains the user required files.
Hope this clears you doubt.