I'm trying to release a program with a client/database approach.
The client and database can be installed on 2 different computers.
What I'm trying to do is an installer that at the beginning asks if you want to install the client, the database or both.
Is this possible? Which section should I modify?
I warn you, I've never wrote an Inno Setup script, I always used ISTools, but if there is no other way, I'm ready to get my hands dirty :P
Edit: a bit more info.
At the moment I have 3 installers, one for the client, one for the DB (which is postgreSQL) and one for PDFCreator.
What I'm doing is copy the files to a directory and then ask at the user what he wants to install: [Run] section, Post Installation.
Yes, it is possible. Take a look at the CodeDlg.iss example. It show how to create a dialog to ask which edition to install. In the case of CodeDlg, it is various editions of a program (light, sponsored, paid) but the concept is the same. I've done this before as well. In my case, during initialization, I read a registry setting and set some variables up to choose which version (client or server) I install. I don't have it here but will get it later and add to this answer.
Related
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
I created a Visual Studio 2010 installer project and added the postgresql-9.2.401-windows.exe file to it. In the "Commit" custom action, I added that file, removed any arguments and set InstallerClass to False.
Now, when I run my application's installer, the PostgreSQL setup starts up, shows its splash screen and then jumps to 100% CPU usage and starts leaking memory for a long time (certainly longer than a few minutes), after which it bails out. Running the .exe on that computer works just fine.
How should I package PostgreSQL in my installer?
Personally I don't like programs that silently install the standard PostgreSQL for Windows. It's deeply annoying to get mailing list posts from people who're asking "What's this PostgreSQL thing and why is it using 88 bajillion megabytes of RAM, I didn't ask for it, remove it now!".
(Yes, I'm mostly talking about a certain annoying gambling card-counting program with the initials PT whose name I will not mention directly).
If you're going to bundle PostgreSQL it'd be great if you could use a non-default port and non-default data directory. If you install a service to auto-start it, don't use the default service name postgresql-[version] but something like myapp-database or myapp-postgres.
This is all done much more easily if you just bundle the PostgreSQL binaries in your installer then create the service yourself with your installer tools or via sc.exe. You may choose to simply pg_ctl start/stop the server from within your program, though this requires some thought about access permissions to the data directory.
The downside is that when there are PostgreSQL updates you need to update your installer. On the other hand, you probably don't want people upgrading PostgreSQL independently of your software updates.
I suggest using the .zip binaries from here and bundling them into your installer directly.
If you really must use the executable installer the documentation contains instructions on silent installation.
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
I need to create setup file for installation of these:
-Web app
-Win service
-Run some sql scripts.
I wanted to do all in one setup. For example I want to make method like CreateSetup and in that method to create setup file which will contain installation/run of above 3 things.
If you have some links or idea how to do it please share.
Thank you in advance.
If I come across some solution I will post it here for others as well.
It might very well be worth your while to sit down and learn WIX, it seems the preferred method of dealing with more complex setups. I haven't done the tasks outlined here, but I did mange to have an installer that set up an application on a Windows Mobile device.
Looking around a bit, it does seem you can install web applications: http://www.codeproject.com/Articles/115036/Creating-WIX-Installer-for-ASP-NET-Web-Application
And a windows service: http://blog.tentaclesoftware.com/archive/2009/01/01/21.aspx
And run SQL scripts: How to run sql script to create database using Wix
It does appear you could even capture what is required to build a SQL string through the windows installer GUI, and use that to know where to run the SQL script, and set up any needed connection strings.
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.