I’ve two MSI files that I want to be installed in one setup installation.
One is an application – EXE file and the other is a windows service that will start and stop the EXE file.
So, EXE file setup needs to be installed before the windows service.
First I create a project for the EXE file that generates a MSI file. After I create a project to the Windows Service application that generates other MSI. So far so good.
If I install each file separated it works well.
But, I’d like to have just one setup to install these two applications,
For what I read it seems that I need to add the EXE project (MSI file) to the Windows Service application project.
I already tried to add it on Prerequisites page as a Chained Package or as a Feature-based, but only installs the EXE project. The Windows Service is never installed.
What mistake I’m doing?
This is not the correct way. You can modify the project that installs your EXE file, to also install and start the service.
Your project that installs the EXE now just contains the file in Files and Folders page. The new step is to go to Services page and add a new service installation.
The linked example from above is a for a Java application, but he same can be applied to any other executable file.
Related
I am using jpackage to create .msi installers for a Java application. The generated .msi files work fine, but I would like for the installer to automatically launch the generated application at the end of the installation. I'm keeping the user experience as seamless as possible, and don't want to offer a user interface - just launch the app when it's ready.
I found this answer: Run exe after msi installation? ... but the script fails when I run the command on the installer with [object Error] message. I've tried a few tweaks, and the script does appear to be able to open the .msi database successfully, but it's not quite the right set of commands for some reason.
An example of the .msi I'm starting from can be found at:
https://github.com/wiverson/maven-jpackage-template/releases
... in the Windows section.
What I need is a script (similar to the EnableLaunchApplication.js posted in the other question) that works with the .msi to simply launch the installed TestApp.exe when the installer is complete. No UI, just automatically launch the app when complete. I can tweak the script as needed to add to my build environment.
The jpackage installer is generated by https://wixtoolset.org/ - jpackage creates and runs Wix to generate the .msi. I would like to just add a simple build step to tweak the generated .msi if at all possible.
I have a desktop application that automatically checks for updates on every start and automatically installs the update silently if one is available. I am using an .exe setup created with NSIS for that and do it with the following steps:
While the app is running I move all application files to the temp folder
I download and silently run the setup.exe file
I restart my application and do a cleanup of the temp folder
This allows me to update the application while it is running. I would like to do something similar with a Wix .msi installer, but I am not sure if and how it is possible. I know there is a silent flag, but I believe .msi keeps track of all the files it has installed so will this work anyway? Can I just do the same thing with an .msi installer or how would one generally handle this? Is it maybe even possible to put all this logic directly inside the installer?
I have C# desktop application created in Visual Studio.
I need to have one executable file, which I can run anywhere. Without compiler or need of having folders of libraries. The .exe file I have in project folder doesn't work alone.
Thanks
Create installable file using any third party software i.e Advance Installer to send your project anywhere.
If it's a .NET application executable then YES you can send it anywhere and run it anywhere having just one file; provided the fact that wherever or whichever machine you are trying to run it; have .NET Framework installed.
Else, you should create a self extracting installer which will not only include the executable but also will have the framework executable. That way wherever you run the installer will first install the framework and then you can run your exe without any trouble.
I'd like to make it so that when users click the "Install" button, the installer file they download to their local machine is called differently from default setup.exe, e.g. myCoolInstaller.exe. Is that even possible with ClickOnce?
A simple option is to use symbolic links. From the command prompt, whilst in your release folder type:
mklink myCoolInstaller.exe setup.exe
Then everytime you publish to setup.exe, your users can download using the more friendly name. Note that this does not update the publish.htm file - you will need to edit that yourself. In our case, we don't use it - we provide a link to our customers directly to the installer .exe
The setup.exe file that is generated by Visual Studio has very little to do with ClickOnce. It simply bootstraps your pre-requisite installs together and launches your actual ClickOnce app (the .application file) when it's finished.
You should just be able to rename it.
when I build solutions in Visual Studio, that generates installer files as .exe and .msi, .exe files are useful for what?
The .EXE file that is created by the installer project is a bootstrapper for the .MSI setup file. It is used to launch the .MSI setup file.
Generally, both will launch the setup program and allow the user to install the application. However, sometimes the setup.exe file will run a custom validation routine to determine if the user's computer meets the minimum requirements for installing the software.
For example, if the user does not have Windows Installer, they will not be able to launch the .MSI file, but the .EXE application will still run and inform them that they need to install Windows Installer first. For .NET applications specifically, the .EXE file verifies the presence of the appropriate version of the .NET Framework, and if it is not present, it prompts the user to download and install it.
You can customize the prerequisites that are required for your application in your installer project using Visual Studio. See these MSDN articles for details on how to do that:
http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/7eh4aaa5(v=VS.100).aspx
Others have commented on the how (.exe bootstraps the .msi) but part of the reason why is that users know that .exe files are the things you run. I don't think your average user knows that .msi files are something that you can click on to install an application.
The .exe file is made for installing the prerequisites of your application.
Let's say your application uses the .Net 3.5 framework, you can tell the installer project to include the installation of the needed libraries if they're not already installed.
You may also deactivate it, so only the .msi is being created.
This page shows how to activate and configure the prerequisites setup, just uncheck the checkbox in order to deactivate it.
You also find more details on the process of Bootstrapping on MSDN:
the capability to automatically detect
the existence of components during
installation and install a
predetermined set of prerequisites
.exe files are useful for executing your programs that you've just built in Visual Studio, assuming you're not doing web applications.
Pretty much every Windows program out there is executed using files with an .exe suffix.
Installer exe files are normally just the msi wrapped in a bootstrapper. The bootstrapper can do anything, but normally its purpose is to ensure the user is running a sufficient version of Windows Installer, then extract the msi and invoke msiexec.exe to start installing the msi. Generating installers as exe's is deprecated these days, but some still do it.