I have made a basic msi project. Then I make a major upgrade package for it. when I run the major upgrade package I found that I must determine the installation path.
Is it possible to let major upgrade package to automatically install into path that user has determined in installation of previous version?
Thanks
No, This can't be done automatically. if the Installation directory of previous is stored in your product registry or some config file, you may read it the same using custom action and set the value of INSTALLDIR property.
In case, if you didn't stored the Installation directory of previous version, then it can be read from the following Key (if stored automatically):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{Product_Code_of_Previous_Install}\
Value: InstallLocation
{Product_Code_of_Previous_Install} value can be read from the public property which is being set in Upgrade table under ActionProperty column.
Related
I've done a bit of googling and haven't been able to find any documentation on this, but I need to upgrade my Seeddms (Document Management System) server from 5.1.25 to 6.0.19.
I am running a Linux Lamp 4.19.0-19-amd #1 SMP Debian 4.19.232-1 (2022-03-07) with a Seeddms web server on it.
I tried copying the contents of the .gz download file of the latest version over my current /var/www/html/dms/ folder and it didn't work, I did a similar thing to update my dokuwiki site so I thought I'd give it a try here.
I am still new to Linux so any advice would be greatly appreciated!
I was able to find the solution, in the seeddms-quickstart-x.x.x/seeddmsxxx/seeddms-x.x.x/doc/README.Install.md.
Here is what is says on upgrading versions if anyone has trouble with this as well. Make sure your server meets the requirement as well.
UPGRADING FROM A PREVIOUS VERSION OF SEEDDMS
As SeedDMS is a smooth continuation of LetoDMS there is no difference
in updating from LetoDMS or SeedDMS.
You have basically two choices to update SeedDMS:
you install a fresh version of SeedDMS and copy over your data and configuration
you replace the software in your current installation with a new version
The first option is less interuptive but requires to be able to set up a second
temporary SeedDMS installation, which may not be possible, e.g. because of storage
limitations. It can be the only option if you change servers.
The first update procedure is only needed if the version changes on the minor
or major version number. Changes in the subminor version number will never
include database changes and consequently it is sufficient to use the existing
data directory and database with the new version. Choose the second update
option in this case.
In both cases make sure to have a backup of your data directory, configuration
and database.
Fresh installation and take over of data
The first update option is to set up a new instance of SeedDMS and once
that is running take over the data from your current (old) instance.
just do a fresh installation somewhere on your web server and make sure it
works. It is fine to use
SQLite for it, even if your final installation uses MySQL.
replace the data directory in your new installation with the data directory
from your current installation. Depending on the size of that directory (and
whether the new installation is on a new server or the old server) you
may either copy, move or place a symbolic link. The content of the data directory
will not be changed during the update. Its even perfectly save to
browse through your documents and download them after finishing the
update. The data directory will not be modified until you actually modify
documents.
copy over the configuration settings.xml into your new installation. This will
effectively make your new installation use the data from your old installation,
because all paths are still pointing to the old installation.
if you use mysql you could as well make a copy of the database to make sure
your current database remains unchanged.
modify the settings.xml to fit the environment of the new installation.
This will mostly be the
httpRoot, the paths to the installation directory and possibly the database
connection.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
Upgrading your current installation
Instead of setting up a new installation, you may as well replace the php files
in your current installation with new versions from the quickstart archive.
get the SeedDMS quickstart archive seeddms-quickstart-x.y.z.tar.gz and
unpack it somewhere on your disc.
copy the directory seeddms-x.y.z from the unpacked archive into your
current installation and make the link seeddms point to this new directory.
copy the directory pear from the unpacked archive into your current
installation, replacing the existing directory. Make a backup of pear before
the replacement if you want to ensure to be able to go back to your old version.
you may compare your conf/settings.xml file with the shipped version
conf/settings.xml.template for new parameters. If you don't do it, the next
time you save the configuration the default values will be used.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
I am using Inno Setup to create an application installer (a big file) and an updater, which is just a small file and contains only files which changed since the previous installation/update. This update file also should increase the number of the application version. I followed this document http://www.jrsoftware.org/iskb.php?updateinstall, i.e. I set CreateUninstallRegKey=no and UpdateUninstallLogAppName=no
Everything works fine except one thing. The updater does not change the version number in the list of installed applications. For example, if I installed the version 1.1.2 with the installer and then ran the updater which has parameter AppVersion=1.1.3. The updated files get installed correctly but the version in the list of installed application (in Windows Settings) still shows version 1.1.2.
I tried to change to UpdateUninstallLogAppName=yes but this does not affect the version number displayed. When I look into registry, I still can see the number 1.1.2.
Any ideas how to solve this?
You will have to change it explicitly in your script.
CreateUninstallRegKey=no prevents any updates to HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall.
As the page you linked to (link to an archive as the page is dead now) says:
The update should not create a new entry in the Add/Remove Programs list, or alter the original application's entry.
You can use [Registry] section entry (as your comment below shows) or RegWriteStringValue function.
In Installshield 2015 Premier Edition, I've created a patch definition which upgrades my application product from version 1.9.7 to 1.9.7.5
In the Installscript MSI project, I've only changed package code, product version and built the patch (Latest 1.9.7.5 release - Previous 1.9.7 release).
Patch (Update.exe) is executed under Admin priviliges (a 1.9.7 release in installed priorly)
The patch 1.9.7.5 will omit to update .exe and .dll component files of a feature application directly install in [INSTALLDIR] (root : C:\ProgramFiles\MYCOMPANY\MYAPP\confapp.exe)
All other component files are updated respectfully ; they're located in their own sub-directories of [INSTALLDIR] as designed in Installation Architecture in IS2015.
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature1DIR\app1.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature2DIR\app2.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature3DIR\app3.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature4DIR\app4.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature5DIR\app5.exe
I'm shipping the newly built applications and have upgraded my .dll files with AssemblyInfo.cs.
Long story short, my Update.exe is only updating 5 out of 6 applications installed.
Any help appreciated if you've already encountered the issue,
Regards,
Can you please add your feature/component/file structure and log file entries that relate to those files in particular? It should look something like:
MSI (s) (B4:4C) [11:30:07:906]: Executing op: FileCopy(SourceName=eulatxt|eula.txt,SourceCabKey=FILE1,DestName=eula.txt,Attributes=512, FileSize=29239,PerTick=32768,,VerifyMedia=1,,,,, CheckCRC=0,,,InstallMode=58982400,HashOptions=0, HashPart1=-1713153497,HashPart2=58557210, HashPart3=1046945815,HashPart4=871163290,,)
MSI (s) (B4:4C) [11:30:07:906]: File: C:\WINDOWS\system32\eula.txt; Won’t Overwrite; Won’t patch; Existing file is unversioned but modified
You also need to check your components and key files. If the key file for a component is not changing in your patch (this is a "small update" or "patch" BTW, not minor upgrade), none of the other files in the component get upgraded regardless of the version changes associated. Remember that component best practices state one binary (versioned) file per component.
From this MSDN article:
Be aware how the Windows Installer applies the File Versioning Rules
when Replacing Existing Files. The Windows Installer first determines
whether the component's key file is already installed before
attempting to install any of the files of the component. If the
installer finds a file with the same name as the component's key file
installed in the target location, it compares the version, date, and
language of the two key files and uses file versioning rules to
determine whether to install the component provided by the package. If
the installer determines it needs to replace the component base upon
the key file, then it uses the file versioning rules on each installed
file to determine whether to replace the file.
If this is an InstallScript project, open Components view and make sure OverWrite setting is set to Always. By default, it is set to Overwrite files by version, then Date, I think. However, I have seen cases when this algorithm did not work for some reason, and some files were not updated.
I want to install OpenSplice DDS using nsis script, but i have to know whether the OpenSplice DDS installed or not in the system (Windows).
Based on the register keys how can we check if OpenSplice DDS is installed or not?
Can anybody provide the nsis script to check DDS installation based on registery keys?
A standard OpenSplice installation does not make any changes to the registry and as such, you can not use checking of the registry key to discover whether or not OpenSplice has been installed. Only if the option to install OpenSplice as a Windows service was checked during installation, information will be inserted into the registry -- just like any Windows service has an entry in the registry. Since it is up to the user to select this option or not, this is not a reliable mechanism to check for either.
A better way might be to check whether the environment variable %OSPL_HOME% is set. This variable is typically added to the environment by the OpenSplice installer; it points to its installation directory.
This answer is based on previous experience with the product. I do not have access to any current version, so the installation process might have changed.
I have release an application with Inno Setup. Sadly this application had installed a DB file as a source file, so if the application is uninstalled then entire DB file is removed.
I'm going to release a new version soon. I would like the new version to override previous one, not install DB file at all and instead create the DB by the application itself.
If I install the new version without ever installing the original one, everything works fine. The application creates a DB file and after uninstalling, the DB stays on the machine.
The problem is that if I had installed the previous version on the machine and then installed a new version, then after uninstalling the new version the DB file is always removed.
Both application go to the same directory with the same AppId.
How can I revoke a file removal scheduled by the previous installer?
You can keep installing a database file if you add the uninsneveruninstall flag. This would leave the file and the directory when the application is uninstalled. Unfortunately adding this flag now won't help, as the uninstall will still remove the database file - the file entry for the database file from the initial installation isn't modified by later installations, so the database file will always be removed. There seems to be no way around this.
What you can do is adding code to your new installer (or uninstaller) that makes a backup copy of the database file. The file and the directory will then be preserved, as the uninstaller does per default not delete anything that the installer hasn't created.
In the new version, I suggest you create the DB file with a different name. That would be a simple way to ensure that it would never be uninstalled by any previous installer.
Your installer for the new version (using some Pascal script), or perhaps the application itself, could detect the DB with the old name, if it exists, and:
copy the data from the old to the new file
perhaps rename the old one as a backup with a different name
or perhaps just rename the file to the new name
You would have to be careful to consider all the possible install, uninstall, reinstall scenarios and not to mess up the data in each scenario.
Thank you for your responses. I agree that the most obvious solution here is to copy the DB file to a new location and forget about the problem. So my upvote goes to mghie.
I managed to achieve what I needed by removing unins000.* files though:
[InstallDelete]
Type: files; Name: "{app}\unins000.dat"
Type: files; Name: "{app}\unins000.exe"
I needed to remove both files. Additionally I had to reinstall all files with "ignoreversion" flag, so that they are to be removed by the new uninstaller:
[Files]
Source: {#SourceFileDir}\my.exe; DestDir: {app}; Flags: ignoreversion
This has some drawbacks of course and is not 100% safe, but works in my case.
Try changing your AppID in your script.
From the InnoSetup help file:
The value of AppId is stored inside uninstall log files (unins???.dat), and is checked by subsequent installations to determine whether it may append to a particular existing uninstall log. Setup will only append to an uninstall log if the AppId of the existing uninstall log is the same as the current installation's AppId.
This is rather an advanced topic (I think).
I would suggest asking this question in the news group of innosetup:
news://news.jrsoftware.org/jrsoftware.innosetup
Please, if you receive an answer in the news group, post the result here.