I would like to know how can I detect if help file is contained in setup file for windows platform application (msi or exe). Is there any method to get this information without installing the software first ?
Of course setup file can be created by many setup makers like innosetup, installshield and so on. So I wonder if there is some universal method to solve this.
For an MSI based install it would be very easy. For example you can use the Microsoft.Deployment.WindowsInstaller interop via C# to open the MSI as an InstallPackageClass then access it's Files collection to see if it contains the file you care about.
For a Non-MSI based install, there is no universal way and in most cases, no way period. See, that's kind of the point of MSI: to have a standards based package rich in meta data to be able to see what it's doing. When you do some proprietary script driven installer you lose that openness.
If it's a MSI file, open it up using Orca, and you can view file names.
For both of them, you should be able to do an administrative install, which would extract the files, but not register anything. Depending on where the exe came from, doing an administrative install changes, since each vendor(installshield, innosetup, etc) has their own way to run an administrative install.
for a MSI it's simply
msiexec /a <msi_filename>
For an exe you'll have to look up how to pass the /a argument.
Related
My scenario is as follows:
I have a client-server application. The client is deployed through an MSI package. I would like to customize the MSI to include some details that are specific for the each installation (i.e. I need to write the address of the server into one of my configuration files; this address is different in each installation).
I am considering the following alternatives:
Unpack MSI, un-compress CAB, modify file, compress CAB, create MSI (as explained in this link). The problem is that I need this to be done automatically (no GUI, no user intervention)
Pass the address as a parameter to the MSI. Then during the installation read this parameter and modify the file. This is far less desirable since creating the configuration file on the client is something that I am not currently doing, and this means adding another component to the client.
Create the MSI from scratch on the server.
If someone has experience doing something similar, I would appreciate the feedback.
What are you using to author your installer? I know WiX and InstallShield both have custom actions designed to update XML files using XPath statements. You can do things like
For Foo.Exe.Config
//appSettings/Add[#key="Server"] set Value = "[SERVERNAMEPROPERTY]"
Then you could write a custom dialog that asks the user for the value to set the property. You can also do silent installs with:
msiexec /i foo.msi /qn SERVERNAMEPROPERTY=MyServerName
Is there a way to discover what installer tool does a product use? I mean, is there any way, checking the files properties or the processes running to discover what setup authoring tool (InstallShield, SetupFactory, InstallAware, Tarma, etc.) was used?
Thanks.
It's possible, but only if you are familiar with all these setup authoring tools. Most of them use custom installer properties, custom actions or custom tables specific only to them.
However, if it's a really simple installer these unique elements may not be used. So it really on a case by case basis.
What product interests you? Perhaps one of us can determine the setup authoring tool they used.
It's not bulletproof, but if you look under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Most products that leave a trace in the add/remove programs applet will have an entry under here.
If you open the 'UninstallString' value, that will include the path to an exe that is invoked to perform the uninstallation. If it's msiexec then you have a product installed by Windows Installer. Otherwise you might need to get hold of the exe and inspect the file's version resource to get a little more information. Note that this may give an inconclusive result if, for example, the uninstaller is a bootstrapper exe that daisy chains a set of .msi packages.
If you need to find out what MSI authoring tool was used to generate the MSI, you might be able to infer this from the summary information stream of the .msi package in the uninstallstring, but not every authoring tools fills this value in.
Properties of setup file -> Version (XP) or Details (7) -> Description, like
Created with Actual Installer
As alternative to above answers I would recommend to open installer's file in hex editor. Then do search for string containing 'install' or something like this. Usually near matched string will be name of program that produced installer package. For example, in my case this was a 'Smart Install Maker'.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".
Due to severe limitations of the Microsoft Windows Installer (MSI) system it is required to create a bootstrapper in order to install multiple MSI files (due to pre/post-requisites). However, this introduces an distribution problem because you now have multiple files that need to be included with the distribution. There are of course multiple ways to distribute this as a single file.
1: An archive
You can put all the files into a single archive that users download. The obvious choice for MS Windows is of course a PK-ZIP archive. But this is not very user friendly. Users will first have to extract the archive, and then run the bootstrapper (which would be called setup.exe).
2: A SFX archive
Instead of distributing an plain archive file you could wrap it into a self extracting archive. Executing this SFX archive would prompt the user to extract and/or run the contents. But this adds yet another prompt to the whole installation process (#1: SFX prompt, #2: bootstrapper prompt, #3: main installer prompt). This is also not very user friendly, as it increase annoyance due to multiple prompts.
3: Single file bootstrapper
Of course there is the option to embed all the extract files into the bootstrapper. This is probably the most user friendly for a normal end-user. However, this is less friendly for system administrators, because usually bootstrappers are less manageable than the MSI files. An admin would rig the system so that all requisites are also installed when the main MSI is installed, thus the bootstrapper would not be needed.
4: Other?
An other unlisted method?
So what do you think is the best way to distribute a installer for MS Windows software that requires a bootstrapper?
We provide a single file bootstrapper for retail distribution and all single-user installations.
Volume licensing customers (e.g. 10+ seats) receive one (or more) MSI files along with instructions and a list of prerequsites that must be installed before our application will run (which slightly differ between XP, Vista and Win2k). The EXE blocks installation if the prerequisites are not installed, the MSI will permit installation under the assumption that the sysadmin knows what they're doing and might be installing the prereq's at the same time, before the next reboot.
Basically the single bootstrapper is for non-sysadmins, people who want a single click solution. System administrators and corporate IT support who prefer more fine grained control over their installation are happy for multiple files, even if it means more work for them. The single EXE file is available publicly, the instructions + multiple files are only available by contacting our sales team.
This method gives us the best of both worlds, as well as the ability to provide different default configurations for home and corporate customers - hints, tips, splash screens, auto-updates and welcome dialogs are all disabled by default for corporate installations but enabled for "single" users.
We use Wix to create MSI files which is hugely flexible and can easily be automated with build scripts.
To chain multiple MSI/EXE files together for distribution via single bootstrapper I would highly recommend DotNetInstaller. I'm in no way connected or affiliated with this product, but it has been a lifesaver on projects for generating highly configurable bootstrappers in unmanaged code.
I wrote up my recent experiences in developing a multi-language MSI and bootstrapper using these technologies here. This talks through the process from start to finish. Using DotNetInstaller you can download and install dependencies from a URL on demand, or embed them directly within the bootstrapper with ease. I did also consider WIX's own SETUPBLD bootstrapper generator and the GenerateBootStrapper MSBuild task but they are pretty basic. That said WIX 3.5 Burn utility is currently in the pipeline and could be a pretty decent alternative once it's released.
Regarding: 1: An archive: 2: A SFX archive
You could use a self-extracting .ZIP that automatically launches a Setup.exe. WinZip offers this support inexpensively. That way, it would be more customer-friendly. It can be configured to launch the bootstrapper without a prompt.
Regarding: 3: Single file bootstrapper
At the risk of sounding like an InstallShield salesman, InstallShield 2009 will take care of everything you're asking about -- it smooths over the MSI shortcoming of needing a bootstrapper. You could use the Release Wizard to create a single-.EXE all-in-one bootstrapper. Or you could create a web-deploy setup that is very small and then downloads the payload from a web site. Or you could put different features in separate .CAB files, and the user only needs to deploy those CAB files corresponding to the features he wants to install. InstallShield comes bundled with dozens of prerequisites ready to add to your Setup.
Depending on your siutation, MSI v4.5 and 5.0 might help you -- they have native support for multi-package transaction chaining. Of course, depending on what OSes you support, you may still need a bootstrapper to make sure the right level of MSI support is present.
I had a similar problem where I needed to distribute some optional support software, MSI installer, and another file just incase the MSI file needed it. I basically created a native application to handle the whole process. I wrote a blog about it here (http://blog.foldertrack.com/?p=45)