I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.
Related
I have a scenario,
On a particular machine, I am installing my custom software with MSI installer. MSI installer is created with PerMachine tag, so software is available for all the users of that machine.
Now,
I installed the software on C:\MyApp\ directory.
Then I modified a few configuration files present in C:\MyApp\Config folder to make sure the software connects with my other services.
I started the application, it's working fine.
Now, on the same machine, I logged in with another user.
I started the application.
MSI windows popup with some progress bar for installation.
It vanishes and the application starts but fails to load.
But all the files I have modified are reverted now, I need to again modify those.
Few points:
My installation direcotry is C:\MyApp, not any custom user directory. So modified files should be for all the users.
I think MSI is rolling back changes when I logged in with the new user.
How to stop this?
Please help
Self-Repair: Windows Installer self-repair is the cause of the behavior you see. See the link for an explanation of what happens. See more here - several links with information on self-repair from various angles.
Short Explanation: Essentially the launching of an advertised shortcut triggers an integrity check of the installed files and if a file or registry setting is found to be missing a self-repair ensues. It will put in place missing files and settings. During this process it will sometimes overwrite changed settings files - the problem you describe (due to various file overwrite oddities of Windows Installer - a long answer with various hints).
Fix?: My preferred fix for this is to not install the settings files and update them, but to rather have your application generate them on first launch - either one file per user or a shared one for all users. You can also use a read-only copy of the settings file that you install to copy to a new file that you generate and update. I also recommend you put these files in a writable location in the user profile and not in the main folder. Your setup will never interfere with these generated files. You can also try to set the hosting component for the files "permanent" and "never overwrite". Not very neat. Here is a whole rant on the subject. The very best solution - in my opinion - is to keep settings in databases and get them on launch. This allows good control of all settings. Look out for network and firewall issues.
I hope this answers your question. Are you installing IIS files? I find commercial tool Advanced Installer to have the better feature list for IIS installation - though I lack enough data to conclude. Some videos here: https://www.youtube.com/c/advancedinstaller/search?query=IIS - WiX is also very good, but without the nice GUI of Advanced Installer.
Note: you really should not install to the root of C:\ anything at all. Windows Installer actively tries to make it hard, and side-effects are likely. You can, however, target the IIS folders - wherever they are located.
Update: I found this old answer on how to allow selective update of settings files - I had to resurrect the linked forum answers from Wayback.
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
I have a quite simple installer created with Wix Toolset. My users complaints that they can't deploy this installer as system user. They have to do it as user. However, I have learned that installers can be deployed as system user. Could anyone tell me what I need to do in my wxs file so that they can deploy it as system user?
We typically deploy our MSIs using Microsoft SCCM as SYSTEM. We use PSEXEC to invoke a CMD prompt as SYSTEM to do our dev testing before sending it to SCCM. There are two reasons an installer would fail as SYSTEM:
1) User error: I can't tell you how many times I've seen packages put into SCCM with invalid command line arguments. One of my favorite is quotation marks get turned into Unicode quotation marks via email transmission. Another is logging to a directory that doesn't exist. Another is forgetting to tell the MSI to run silently. It just sits there and hangs. Another awesome one is typing the MSI name wrong. It's especially awesome because they almost give me an SCCM log when I ask for an MSI log. No MSI log means it's not the MSI's fault.
2) Installer design error: Have you tested your silent installs? Do you have any custom actions that make assumptions about the user context / environment? One of my old favorites (not) was InstallShield InstallScript custom actions that would fail due to a poorly designed DCOM interface for talking to the MSI session handle. It's been almost 10 years since that was fixed but I still come across installers now and then. Another example is assuming that the user will have rights to another machine or the internet (SYSTEM typically has neither in a corp environment.)
I'd start with testing as SYSTEM using PSEXEC. Log the install and see what the error is. Otherwise you haven't really given us any details to give a specific answer for.
You should get them to do a verbose log of what happens when they do the install. There are issues sometimes related to user specific locations, for example a file going to the user's personal folder, what does that mean for the system account? Or the install or a custom action may assume that a drive letter mapped for a user is system wide (they're not - they are per user) and that can cause errors. That's what Chris is saying too - the context matters. The system account does not have access to the interactive user's desktop, the network, profile locations that make no sense for a non-interactive account and so on.
I also am a SCCM user and regularly deploy apps through SCCM... This WIX installer also drived me crazy. But Christopher's reaction helped me...
1) If Wix installers get tested using PSexec, they probably work, SCCM, I don't know what it is, but installs keep failing without apparent reason. (but it fails installing as System is true)
Solution: incorporate psexec in your script in SCCM...
add your setup.exe & psexec.exe in your source folder. Use following syntax in your setup script:
copy psexec.exe to your software source location.
%~dp0PsExec.exe -accepteula \127.0.0.1 "%~dp0setup.exe" --quiet
2) #WIX dev team: also try to test with SCCM!
3) if above fails, you can also extend the suggestion with:
add following syntax in your setup script:
c:\windows\system32\net.exe user /add WixHelpInstaller PaSSW0rd
c:\windows\system32\net.exe localgroup administrators WixHelpInstaller /add
%~dp0PsExec.exe -accepteula -u .\WixHelpInstaller -p PaSSW0rd \\127.0.0.1 "%~dp0setup.exe" --quiet
c:\windows\system32\net.exe user WixHelpInstaller /delete
How can I create an automated Installer for a program that has a regular Installer with questions like:
Install Directory,
Accepting License,
Creating Icon on Desktop
etc...
Assuming that I am OK with building an Automated Installer for every program I want to separately, Or i want to put files in a Self Extracting Archive and run the Installer after unpacking.
Do I need a third party program for it? Should I use Command Prompt? Do I need to learn Lua? (I'm learning C#)
EDIT:
To clarify I'll use an example:
Let's say i wrote a program but that program has a requirement, like
DirectX, or Adobe Air, or Maxthon Browser.
I wrote my program in such a way that I have to be sure that that is
installed in a very specific Drive/Folder on the PC or with some
specific preferences/parameters.
I include an installer for this program, but I want to specify where
it gets installed on the PC and with what parameters.
Preferably Installing this requirement right after or during the
Installation/Extraction of my own program.
I'm looking for a way to be able to run the Installer of any given program and navigate through the install wizard of it with out the user having to/being able to change the settings I need (with the foreknowledge and permission of the user of course).
It doesn't need to be silent install or anything.
I have rewritten my answer.
Your mentioned setups requirements seem very common to me for the class of installation programs (setups) and not at all unusual.
Generally you have two options:
You write everything on your own, you create the install dialogs, the way the settings are saved, and so on. Then you are fine with C# (or any other language).
It is quite uncommon to do so, because it is time consuming, and you are reinventing things which have been solved in standard ways several times. Moreover you will fall in common setup error traps which are maybe already captured (or at minimum documented) if using tools.
If you want to use a tool, it is your first decision, if you want a tool based on MSI (Windows Installer) or not. MSI is the most powerful and most industrial-accepted setup technology in Windows, but it is a quite complicated matter, and no tool can shield this 100% from you. Google for WiX (Open Source) or InstallShield as starting points for MSI tools but there are of course more.
Some tools are already integrated or integrateable in Visual Studio for example.
Selfextracting tools are a starting point, but the following tools offer far more and are a good intermediate way between the extreme points SFX and MSI:
InnoSetup
(has also a home here on SO).
Nullsoft Scriptable Install System (NSIS) on SourceForge
One self extracting program in Windows I want to mention, because it is not widely known, that "IEXPRESS.exe" is already included in the OS.
Concerning your special question of navigating through the install wizard:
Every mentioned tool has ways to save install settings and of course is deciding which settings are changeable by the user part of the 1*1 of setup creation. With the tools you can design the install dialogs like you want consisting of the parts you want.
I hope I got your point.
P.S. While most tools have kind of a scripting language or something similar included, you are normally free to extend the installation process with your own actions written in nearly every programming language you like.
I'm developing an "installation" like cocoa application wich needs to take care of some http request, some file system reading, copying files to /usr/share, set up cron (not launchd) and ask some information to user.
I discarded PackageMaker since I need more flexibility.
Currently everything is going well, but on my last installation step, I need to:
Delete my previously installed application folder (if exists). It's always the same path: /usr/share/MY_APP
Create again the application folder at: /usr/share/MY_APP
Copy application files to /usr/share/MY_APP
Update a cron job
It's very important that /usr/share/MY_APP keeps protected with administrative privileges, so a regular shouldn't delete it.
What would be the best approach to implement those steps?
BTW, I'm using Xcode 3.2.
Thanks a lot!
Carlos.
Between the preflight script, the postflight script, and perhaps an Installer plug-in for the custom UI, I see no reason why you can't do all of this in PackageMaker.
Note: “Installer plug-in” is a little misleading. The user does not have to install the plug-in somewhere as a separate step; you include the plug-in inside your package, and Installer will use it from there.
The relevant document is a ReadMe file in a sample code project. There's also an Installer plug-in project template in Xcode since 2.0.
Also, an Installer plug-in won't get used if the user does a command-line installation. Of course, they can't install from the command line at all (which includes remote installation onto an office or lab full of machines) if you write your own custom installer.
By the way: Why /usr/share? What are you putting there? There may be a better way to do what you're really trying to accomplish.