I work part-time as a computer tech at the local high school. They needed a system to keep track of all the computers in the district (things like physical location of the machines and serial numbers for inventory), and told me to keep it on a budget. I sat down and wrote a little thousand-line script in Perl/Tk, which accesses a PostgreSQL database on the local server.
I also successfully wrote a launcher in C++ and compiled it with bcc32, so they can single-click the launcher executable to start the program without having to type anything into DOS. That works fine, and I can load this program myself by manually installing all the dependencies for it by hand.
I would like to build a setup program to automatically load the PostgreSQL application, Strawberry Perl, as well as the Tk, and DBD::Pg libraries, and finally, of course, the folder my application is stored in. It'd be nice to be able to create desktop shortcuts or start menu items too.
Has anyone had any success with software to generate .MSI files for Windows Installer on Windows XP and above? If so, what did you use, and did it cost any money? Alternatively, where do I need to begin reading in order to write my own setup program?
Nullsoft Scriptable Install System
I'm not sure if this will do everything you want, but have you looked at Win32::InstallShield?
Related
I work at a retail store, where I get new computers in all day that I need to uninstall certain programs from (like McAfee) and install certain programs on (like Java, Silverlight). Until now I have been using deCrapifier and ninite to get this done, but i was wondering if I could make a script that would automatically do this. A script that i could put on a USB and just run one time on each computer.
Could i accomplish this using a powershell script mabye?
Yes, you can! Provided you know the software you are going to install, and have administrative rights. It will take you some time to get it right as you need to detect each of the software separately and potentially follow different steps to uninstall, but nothing is impossible.
Many of your suggested examples (such as Java, and SilverLight's /q switch) have "Silent," or "Quiet" installers that do everything for you. These are simple to launch from a batch file, or even via PowerShell if you'd like.
Additionally, for uninstallations, if you know the application's name as it exists on that box (exactly), you can use PowerShell to uninstall applications, as well.
Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.
I develop and maintain a bioinformatics application suite of 50+ scripts and its deployment process is a mess:
Entire suite is in one big git repository. It has lots of CPAN dependencies, and dozens of internal modules as well.
Development platform is Linux.
Deployment platforms are Windows (20+ users), Mac (10+), Linux (2-3). Most are not 'power users'.
For windows, I have one installer (made with NSIS) for strawberry perl + required modules (ie, I installed strawberry on a windows box, installed all modules and zipped c:\strawberry), and another installer for the suite-- I did this b/c the suite is updated a lot more than the list of required modules.
For Mac, I bundle perl 5.14, all required cpan modules, and the application suite into a double-clickable installer. I don't use the system perl b/c it tends to be out of date. I bundle everything together unlike on windows b/c I suck at mac.
For Linux, I handle their installations manually since there are only a few of them, and they use different distros.
This is obviously a mess that grew organically over several generation of developers. Ideally I would like to create cpan-installable distributions out of the internal libraries and various groups of related scripts, and use module dependencies to let cpan install them for me.
But I'm not sure what the best approach for this is, b/c I'd still need distribute perl itself, would have to write some sort of non-command-line interface to CPAN, control the exact versions of 3rd party CPAN modules, point it by default to my "DarkPan" where I would store our modules, how I would push updates, etc. etc.
I don't think I can use PerlApp or Par since afaik those are for bundling single scripts, not an entire suite of them.
Any advice highly appreciated.
Besides the 3 platforms mentioned (more, if you count the Linux variants), you really have a couple different problems:
Deployment of a standard known-good Perl executable and libraries (CPAN modules).
Deployment of your Perl scripts and modules.
Once upon a time, I supported a large Solaris Perl installation. I tried for a while to stand up a Linux Perl installation "side-by-side", re-using the same CPAN modules. Didn't work. The big problem for me is that a fair number of Perl modules require compilation, which means they target a specific platform. I ended up just with 2 installs, and always remembered to install a new CPAN module in both areas.
We're now 100% Windows, so I don't have the same issue. However, we do run Perl off a shared network drive. All the users map this drive, and run a Registry script that associates .PL files with the network install of Perl. (See my answer to this other Perl question.)
So, besides the mapped drive and the Registry script, users don't need to install anything. Even the CPAN modules are picked up from the network. This solves item #1 (for Windows only users).
Same thing holds true for item #2: the scripts are stored on a network drive (same one) and the users run another Registry script to include the scripts folder in their search PATH. We edit our scripts in one area, and have a "Check-In 'n Release" ("CINR") that we use to, well, check-in and release scripts to the area the users point to. The users can double-click the scripts in Explorer, run them in DOS, or even better yet get them included in the contextual-menu in Explorer, etc. (Actually, we use a .NET application to map the drive and make all these settings for the user, but it can be done much simpler.)
So, how does this help with the other platforms, Linux and Mac? As I ran into with my Solaris/Linux experiment, I think you're stuck with different Perl installation for all 3 platforms, although you should be able to reach the same network drive for your Perl scripts and modules.
The Perl installation might even be OK on a network drive for the Linux users. It's probably easier for them than the Windows users. Mac users are tough. I administer a home Mac network, and I think network drives are very difficult to do in Mac OS X compared to other OSes. It should be as easy as in Linux since so much is the same, but there are very strange problems (for me) mapping NFS and SMB drives. AFP drives are a little easier for the user to map manually, but not so easy to map programmatically.
My Mac recommendation is to try using Platypus. It's definitely great at bundling scripts into a double-clickable application, although your interface options are limited to output only (no user input allowed during execution that I can tell). Not sure if you could put an entire Perl installation into the Platypus app or not, but if you could the paths figured out, you might be able to.
Good luck!
You may wish to check out CAVA packager. It can deal with multiple scripts in a single package.
Okay, I am trying to write an installer that installs multiple programs. The installer needs to be able to either get the files from a web server, or be able to package the files into a single installer file.
The end result I am looking for is a user hits a webpage, they can click a link to download a single installer file and the installer goes ahead and installs each of the programs. Quiet installations would be preferable but not absolutely necessary. I am trying to make this as user friendly and idiot proof as possible.
Grabbing the installers for each program from a web server would be preferable so it always grabs the latest version and I will not have to tweak the installer script each time the programs are updated.
I have looked into NSIS and MSI, and neither seem to be able to do what I need. I have entertained the idea of using Java Web Start to run a Java program that can install everything, but I am not sure the plausibility of that. If that is possible, then the user would not even need to run a file the Java Web Start would just take care of everything.
Perhaps Ninite will help.
If not, there are two possible solutions:
You can try using a MSI wrapper which installs the applications as prerequisites or through custom actions. It's dirty and complicated, but MSI is a standard.
You can write your own application which handles the installers. This is most likely the best approach.
I have a really trivial perl script that I would like to distribute to a number of clients who are not very computer savvy. They are all running Windows XP or above. Furthermore, it is safe to assume that they do not have Perl installed on their systems.
I'm looking for a Perl module or other solution that would allow me to do the following:
The application should auto start upon login and minimize to the system tray until the user expands it by clicking on the system tray icon.
When expanded from the system tray the application should provide a simple Windows GUI to the script. The GUI is super trivial: a status line showing the status of the application and a "Do stuff" button that will trigger the processing of the applications business logic.
Windows-style ideally wizard based installation. I'd like to be able to able to distribute an [application-name]-install.exe that would guide the user through the installation. Perl plus dependencies should be installed behind the scene.
Are there any Perl GUI toolkits and/or installation tools that would help me achieve these things?
Win32::SysTray
Win32::GUI
PAR::Packer provided executable wrapped into NSIS
There are many more ways to do it. I think these modules will get you started most easily.
I am using perlapp from ActiveState to compile scripts into self-contained exe. It is commercial, but did not have problems I sometimes ran into with PAR/pp.
When I need to package more than just .exe (database drivers, configuration, templates, etc), quick installer can be made with InnoSetup.