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.
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 have a question concerning software updates. Currently I install new releases into a different folder each time. The user is then required to re-enter configuration parameters. This of course is not too optimal. The software is Windows forms and I use the settings. Settings file.
So the question is what happens if I install a newer version into the same folder as a previous install? Will files just get replaced? What about if I have added settings in the new version? Will they be merged?
Anything to watch out for?
Thanks
When the MSIs are related, typically you can only have one instance of it installed at a time. If that's the case, first the earlier version may be uninstalled, so the question is whether the files that store the settings are removed by uninstalling your MSI.
If the MSIs are not related, you can get into a world of pain by overlapping their installations (probably breaking component rules by having two different components describe the same file in the same location, but with a different component code), yet the core question comes down to the same thing: will the updated installation lay down the file that stores the settings.
These are likely the same question, as the easiest way to remove or install a file is by including it in the MSI directly. (There are other ways, but I'm assuming you're not using those yet.) If the file is not part of the installation, nothing will happen to it, and the answer to your question comes down to what your application does when it runs with a settings file created in a different version. If the file is part of the installation, and component rules are not being broken, it will either be uninstalled then freshly installed (wiping any configuration), or per File Versioning Rules and Default File Versioning, the file will either be left untouched or completely replaced with the new version. Windows Installer doesn't know how to merge your settings file.
Thanks for taking the time to answer my question.
So bottom line I should just avoid these issues and install in another folder. I should also make a copy of the settings and put them in my own file which can be used to update my new installation. That would be the safest route I guess.
Thanks
I have a DLL that is installed with a WIX MSI. I want to create a patch that will allow an end user to run and automatically update that DLL.
I've been able to successfully get the patch created and the DLL does update ONLY if I update the DLLs version number. This is a pain because I'm not really interested in versioning the DLL necessarily every time I patch. I want to do this without changing the version number of the DLL.
I'm hesistant to share this with you because it's a hack that's usually reserved for when some vendor gives you a DLL and they have failed to follow the component rules and versioned the file. It's really bad form to do this yourself in house.
You want to google "WiX Version Lying". Basically use update the File#DefaultVersion attribute in the WXS to specify a higher version number. (Frequently 65535.0.0.0 ) This tricks MSI into always overwriting the file.
But it really would be better to just automate the versioning of your DLL's as part of the build process so MSI has real data to work with and you can easily audit the deployed environment.
Can ClickOnce be configured to delete off old published directories?
Or
Has anyone written some code that will delete off these publish directories (maybe keeping the last 10)?
Currently, every time a ClickOnce Publish is done a new directory is being created on the IIS Server. This NEW directory contains a copy of the whole application, which is downloaded. The old directories do not seem to be used anymore and is just taking up a lot of space.
Here is a sample of the directory names being created. As you can see the application version number is being used in the name.
EduBenesysNET_1_0_1_0
EduBenesysNET_1_0_1_1
….
EduBenesysNET_1_0_1_192
EduBenesysNET_1_0_1_193
We have had 194 (zero based) builds with each directory staying out there. With the size of one build being about 50mb, you can see how keeping the old directories out there will start to eat away at the disk space.
The way our application works is you always have to download the latest version. You do not have an option to skip the download so I am hoping that deleting off the old directories should not be a problem.
Good question (+1) - one would think that this should be possible somehow ...
Looking a bit closer though reveals that the observed publishing behavior is not actually a feature of the ClickOnce technology, rather one of the Visual Studio Publish Wizard - see for example section ClickOnce publish folder structure in ClickOnce Publishing Process:
If you manually generate or update a ClickOnce application publication using either Mage or a custom tool, you are not constrained to this folder and file structure. For any particular ClickOnce publication, the chain of dependencies includes the following: [...] [emphasis mine]
The Walkthrough: Manually Deploying a ClickOnce Application yields the same conclusion, i.e. the folder structure in use by VS is simply a (reasonable) convention/approach.
Unfortunately the VS Publish Wizard doesn't seem to offer deleting older versions indeed, at least it is neither visible nor documented somewhere. However, given the resulting folder structure is just an artifact of the build process, you might as well add a custom build step doing just that - figuring out the details (i.e. accessing the VS automation properties to derive the last published version etc.) is outside of the scope of your question though ;)
Regarding your sub question:
I am hoping that deleting off the old directories should not be a problem.
Definitely not a problem, it just depends on how many of these you want to keep for rollback operations eventually, see e.g. Can I delete previous old versions from Publishing Location created by ClickOnce?
The short answer is that this is not something that is built into Visual Studio or ClickOnce deployment, and you will have to find another way to do this, perhaps through a script that you run on your server.
You can delete all of the versions except the current one if you push updates as required updates. If you don't do that, you'll want to keep two versions in case the user reverts back a version.
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