Our company release a new version every month, with the latest data. We currently supply a CD with the installation program to our customer. We had the request to create a MSI file.
I am looking for a MSI tool that simply create/copy a folder on the C:\.
In the best scenario the solution would be an application that we only have to install. We do not want to program it all.
You can try WiX toolset with the help of WiX Tutorial. It should be quite easy to make a simple installation.
And don't forget to think about Upgrade policy: whether the installed package should be automatically updated with a newer one.
Better approach will be to use ClickOne for automatic application updates or something similar.
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
I need some help regarding Install4J and the auto online update function.
We have a JRE bundled Install4J installer which works fine. We use the auto online update functionality which works fine, too. All this functionality in integrated to a continuous integration process in TeamCity.
Unfortunately the update installation setup file has a size of around 100MB which is inconvenient to download if we only want to apply a patch or a minor update.
As far as I have understood from other similar questions and the Install4J documentation the right way to deal with that is using a second project file with another application ID and setting up an Add-On-Installer which only contains relevant files and points to the full installer application ID.
To enable the auto online update functionality I have to upload the update.xml file from the Add-On installer, am I right?
By the way, does the Add-on online auto update procedure automatically detect the locally installed version correctly?
But in that case we have to adapt the add-on installer each and every time we are deploying a new patch or minor feature which is difficult to implement in the CI process.
Is there a way to configure an Install4J installer so that it automatically gets the information online which elements have to be updated so that the download size is as small as possible and we could just use one default add-on installer which contains all sources beside the JRE bundle?
Something like an online incremental update procedure which is managed internally by Install4J?
Thank you.
You should never use the add-on installer for updating, because it cannot change the version number.
In order to get smaller update installers, you create a second project where the distribution tree only contains the changed files - or at least does not contain some large files that did not change. To do that, you simply copy the original installer and delete the files in the distribution tree that you do not need to update.
Then you build two sets of installers, those for a new installation and those for the update.
I was trying to create an msi setup for a windows form application. This msi should only installed if the local system has Access database engine 12.0 installed on it.
So I tried to put a lunch condition in the visual studio installer. Now if I want to make this driver as a prerequisite for the new application to get installed I need COMPONENETID of this driver So that I can put a condition in launch condition.
I have and exe for Access database engine 12.0 but can't figure out the componentid of it. I tried to use ORCA tool for this prupose but ORCA tool only work with .msi not with .exe. Can someone please help me out with this ? Thanks in advance.
If you have a tool like WinZip (there'a a free eval version at time of writing this) you can open that exe and WinZip will extract the files out for you without installing it. There will be an MSI file (called AceRedist.msi last time I looked) and then you can use Orca in the way you described.
Is there any reason that you are taking this approach to detect the presence of a pre-requisite? In your case, the pre-requisite here seems to be Access database engine 12.0.
IMHO, there are definitely standard ways to detect the presence of Access database engine 12.0. A simple google took me to the following link:
https://community.flexerasoftware.com/showthread.php?201524-Determine-Microsoft-Database-Access-Engine-Version
Relying upon a specific component GUID from a 3rd party vendor is definitely risky and might lead to unnecessary maintenance.
Regards,
Kiran Hegde
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.
I currently have a project with an installer I made with NSIS, but I would like to have an update to new versions that only has the changed files and will show a changelog. The target platform is windows. What methods/suggestions do you have to do this?
You might want to reconsider using NSIS. If you are into patching and distributing updates you will probably get the most benefit from using an installer technology that utilises the Windows Installer capabilities (msiexec).
NSIS is basically a program that runs and does what you want whereas a Windows Installer type installer forces you to split your application into features and components which can be managed by the windows installer msi service. MSI will track things like what versions of products you have installed, whether running the installer again will run in maintenance mode, whether you are allowed to install 2 products of different versions, whether a patch can be applied to a particular version of a product or any other question relating to updates and installs.
Basically most of the stuff you are requesting will be available out-of-the-box if you change to a Windows Installer technology. Whereas if you use NSIS (which doesn't use Windows Installer technology) then you will have to implement it all yourself.
Just as an example there is a pretty comprehensive installer builder called AdvancedInstaller ( http://www.advancedinstaller.com/ ) that sounds like what you want.
Alternatively, if you want to spend the rest of your life trawling forums and newsgroups then there is an open source product called WiX that does something similar ;)
In spite of my previous comment I have written a 5000 line installer using NSIS with 13 custom pages. I have even looked at patching and it's a bit of a hack. The main bit of advice is to make sure you are patching the version you think you are patching then use one of the patching plugins available.
There are several patching technologies that compare files and produce patch change files and the NSIS code required to "install" them. I have found that NSIS Patch Gen did what I wanted pretty well with the least amount of hassle. The documentation is a bit thin but once you figure it out you think "Oh yeh".
You are probably going to have a little bit of trouble with an automatically generated Change Log. I would suggest that you create the Change Log yourself (or at least add the extra changes to it with each application change you make) and just include it as if it was a normal application file and let the patch generator update it.
http://sourceforge.net/projects/nsispatchgen/
One possible way would be to store an XML file on your download server that has each released version and a list of files that changed for each release. The installer would write a registry key on install of the version of files it installed.
Then, on update, the installer downloads and parses the XML file, and finds any nodes that have higher version numbers than what is currently installed. You display all the files in a text box on an installer page, and when the user confirms, the installer downloads all the files, and then updates the registry to the latest version.
are you familiar with cURL?
http://www.shininglightpro.com/products/Win32OpenSSL.html
http://curl.haxx.se/download.html#openssl
it will download any protocol, and you can use it to download your files. it's a commandline app.
in the installer, schedule a program which should check first to see if the main program is running or not and quit if it is running if not, calls curl to download a batch file from your site with the updates, then runs the batch file.
the batch file it downloads updates the app by downloading the correct files using curl.
the process should run maybe every 2 weeks or once a month, depending on how often you update.
the uninstall part of the installer should be capable of removing all parts of the app in question,including any updates. this can be accomplished by removing all files from that subdir of program files.
RMDir /r /REBOOTOK '$INSTDIR'
RMDir /r /REBOOTOK "$SMPROGRAMS\$StartMenuFolder"
Delete '$SMPROGRAMS\$StartMenuFolder\gpl3license.lnk'
Delete '$SMPROGRAMS\$StartMenuFolder\readme.lnk'
Delete '$SMPROGRAMS\$StartMenuFolder\${PRODUCT_TITLE}.lnk'
DeleteRegKey HKCU "Software\Your major subkey\${PRODUCT_NAME}"
DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT_NAME}"
DeleteRegKey /ifempty HKCU "Software\${PRODUCT_NAME}"
PRODUCT_NAME is a !define I made because I use these nsi files like a template.
this is only a piece of the installer file's uninstaller section.
I've been able to create a patch updater program for my Windows app (a CLI which uses NSIS as its installer) by releasing the app to my personal CDN (or some hosting platform) and taking advantage of Node.js modules like path to replace the binary (using a similar procedure to equinox.io) with a given version from the CDN and winreg to update the Windows Registry accordingly. Since I've namespaced my Windows Registry key, the uninstaller still works for it.
If anyone wants more details on this, please ask. I'm happy to help.
Some compilers like Delphi make a lot of changes in the final executable even if you change a little part of your code.
So first you should see if it worth patching.
Another consideration is patching by itself.
Patching maybe blocked by some Anti Virus Software specially in some system folders.
and finally incremental patching data size can grow beyond the original files.
Based on above subjects I don't suggest you patching.
Use full installers instead