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.
Related
Is it possible to install third-party application alongside my application on my own application setup?
Let's say I were to sell some of my application, and in order to run my application on client's computer I would also need to run PostgreSQL. Is it possible to install it beside my application in my setup?
I am such rookie on that subject and don't really know where to start.
(I should mention that I am particularly interested on deploying Windows applications)
All commercial software will feature ways to help you achieve this as a built-in feature. Essentially you wrap it all in a setup.exe launcher / bootstrapper / downloader and this executable will install your prerequisite components before your own install is run, if they need to be installed.
Please see these answers for some further information on deployment tools and their features:
How to create windows installer
Simple List View of Deployment Tools
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
The open source WiX toolkit features a component called Burn to create such setup.exe launchers / downloaders / bootstrappers. Writing WiX XML markup code is necessary to use this Burn feature. Commercial tools Installshield and Advanced Installer provide GUI to build such setup.exe files.
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.
Situation: I've already written an ActiveX control for my IE users which works perfectly. I build the .ocx, CAB it up, sign it, and put it on the site with an EMBED tag. Users load the page, the yellow bar shows up asking if they want to install it: all they have to do is click it, and we're off.
Now I need to build support for FF, Chrome, and Safari (on Mac). From my research, NPAPI is the way to do this, and Firebreath is supposed to make it easier. But from what I have read, deployment is not so easy. Windows users would have to run "regsvr32" on a DLL (which none of my web users would actually do). I have no idea what would happen on a Mac. I believe the user has to copy it to a directory like /Library/Internet\ Plugins/, which is also a non-starter for deployment. Firefox users would download/run an .xpi. Chrome is supposed to run a .crx.
Does anyone out there have experience with this? How do you do a easy-for-users-to-run deployment of an NPAPI plugin for the other big 3 browsers?
This is a question that is raised a lot by FireBreath users, so it's probably about time I responded in more detail on a forum that is easier to find than the project google group.
First of all, to clear up the regsvr32 thing, FireBreath does indeed support "self registering" for all browsers; that means when you call regsvr32 it installs registry keys not just for IE but also for NPAPI browsers using the methods linked to by DReJ (+1 for that info, btw, thanks. Many don't know where to find it).
However, self-registering DLLs is highly discouraged in the installer world and by Microsoft. There are a lot of reasons for this. You've done a pretty good job of summarizing the other install options in your post; You can use a .cab on IE and a .XPI on firefox, but of course those don't help you on other browsers.
The method recommended by the FireBreath team (which I lead) is to use an MSI installer for all browsers. Personally, I dislike having things work differently on different browsers for an install, so I use javascript to detect the presence (or absence) of the plugin and then prompt the user to download and run the MSI installer.
FireBreath has "built-in" support for building MSI installers with WiX. If you install WiX 3.0 or later on your machine and re-run the prep script it will create a _WiXInstaller project that will build a basic MSI to install your plugin for all browsers as part of the Visual Studio build process. You can modify the .wxs template that will be left in your home directory to customize it.
More info can be found on the FireBreath wiki:
http://www.firebreath.org/display/documentation/WiX+Installer+Help
http://www.firebreath.org/display/~me#iaincollins.com/Potential+Installer+Improvements
If you are really in love with using your .cab installer for IE (I've had problems with them, but some seem to have good luck with them) you can distribute the MSI file inside your CAB and have it run when the CAB is installed. The advantage to this is that when you install the MSI it installs everything for IE, Firefox, Safari, Chrome, and Opera (as well as other browsers which are compatible with the same plugin technologies that those browsers use).
As a quick note, the reason that an MSI is the ideal solution for installing plugins (as opposed to using something that calls DllRegisterServer like regsvr32) is that the MSI is transaction based, so when you uninstall it will always reverse what was put in; that means that you don't have to worry about supporting uninstalling 10 different old installer versions that put things in different places, etc, because the MSI system takes care of uninstalling everything cleanly when you upgrade.
Hope that helps!
For NPAPI plugin you shouldn't run "regsvr32", in Windows you need to write some stuff to the register and on Mac or Linux you need to copy the plugin to specified locations (see "Installing Plug-ins"). I think the easiest way to deploy NPAPI plugin on Windows is to create windows installer that will install both activeX and NPAPI versions of the plugin (for example, you can look how deployment is done for commercial plugins like Unity3D, Roozz or Silverlight). The same is for Mac - just create installer.
I'm not aware of any way to install a plugin from within Safari.
Also, keep in mind that while you may think of the extension-style deployment as easier for users, it's not all that uncommon for Mac users to use more than one browser. If you make them re-install your plugin in each browser they will be confused (since that's not how browser plugins are generally deployed on the Mac) and annoyed. An installer or a manual drag-and-drop installation are the standard ways of deploying plugins on the Mac.
I'm sketching an application deployment process for a bunch of relatively complex desktop applications. We have both native and Java apps, so the deployment must be able to check for existence of the JRE and install it if needed. Some of the apps depend on special hardware, so the deployment must also be able to launch the necessary driver installers. Some of the apps are multiplatform, and preferably the same mechanism should be able to create Windows, Linux and Mac OS X installers. That is:
The installer must be able to install, in addition to the application itself:
Java Runtime Environment.
Drivers (hardware) - that is, launch other installers.
The installer builder must be operable from the command line so that it can be integrated with an automatic build mechanism that generates installer packages for each platform as nightly builds.
In addition, I need to create "update from the web" mechanisms for the applications. It could be included in the installer, or it could also be a separate custom mechanism built into the application.
Now, this is getting a bit complex, and I suspect that there might be no single installer that could do this all. Therefore I'm thinking between two fundamentally different approaches:
Platform-specific mechanisms: NSIS would create .exe or .msi for Windows, XXX would create .deb for Ubuntu, and YYY would create .dmg for OS X.
Cross-platform installer that would handle all the requirements above: ZZZ?
Any recommendations? Some options that I've looked include:
NSIS - Excellent, but Windows only.
IzPack - Good, but requires JVM to run.
Is there an universal tool for this, or should I just pick an appropriate tool separately for each platform? In the latter case, what would be "NSIS equivalents" for Ubuntu and Mac OS X?
I have some recommendations as follows.
Use WIX (Windows Installer XML) for creating MSI installers for Windows
Use Package Maker (part of XCode tools) on MAC OS X, preferably the command line version
Write wrapper scripts (in Python or so) to drive the over-all installer creation process.
to aggregate all the components you need to install (may be from ur version control system)
generate necessary files for Wix and Package Maker as much as possible
to run the packaging tool and generate the package
Make sure that the overall installer creation process is a simple one command operation overall (with options to create different versions of your package based on criteria like release branch etc.)
Overall, developing this workflow requires some initial effort and quite a lot of thinking. But the end result is quite worth the effort.
I haven't done this on the Linux side, but I guess would use RPM/DEB on that front in this workflow.
BitRock InstallBuilder meets all the requirements, including being multiplatform and providing an autoupdate mechanism
You should take a look at InstallJammer. It will definitely handle the cross-platform elements that you want and can even add entries to the DEB and RPM databases on the target system during installation. OS X support is still experimental, but it mostly works.
For .net 3.5 SP1, Microsoft have the new client profile which installs only a subset of .net 3.5 SP1 on to Windows XP user's machines.
I'm aware of how to make my assemblies client-profile ready. And I've read the articles on how to implement an installer for ClickOnce or MSI.
But I've been using Inno Setup for my project so far and I'd like to continue to use it (as an Express user, I can't easily make MSIs), I need to know how to use the client-profile installer in a custom environment.
There is an article on a Deployment.xml schema, but no indication of how to write one, package it or anything else. Can someone explain this process? Finding the articles I linked to alone was a painful search experience.
Microsoft has now shipped the Client Profile Configuration Designer (Beta).
This designer lets you edit the XML files with some limitations, this isn't a 'Google beta' by any means.
Information and download
Can you clarify: Are you trying to write an installer for your app, which depends on the Client-Profile, or are you trying to write a custom installer for the client-profile?
I haven't used it personally, but if it's anything like the dotnetfx 1 and 2 msi's, you basically have to just invoke it's executable yourself from your own .exe file, or from an Msi BEFORE the InstallExecuteSequence starts up - you can't "embed" those in your own app, MS go out of their way to tell you not to do that due to suckage of MSI.
Client profile works only on clean XP. If your user as .Net 1 or 2 installed, client profile wont install...
You have an offline version (integrating Full .Net3.5 Install in case Client Wont install) 200 to 300Mo don't remember
Online version will get required files.
You can call a silent install from the first steps of your install.