Installshield 2015 : minor upgrade (Update.exe) not replacing files for one feature - .net-assembly

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.

Related

Upgrading Seeddms to 6.0.19 from 5.1.25

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.

How to make major upgrades get default target path from previous installation

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.

Updater created with Inno Setup does not change the application version

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.

How to check if files exist in .ism without using InstallShield

I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:

InstallShield VStudio project is installing app.config file instead of merged MyApp.exe.config

Using a InstallScript C# .Net Wizard to connect to a WinForms solution where I used the dependency scanner to identify project outputs.
The install package is copying the un-merged app.config file to the target directory instead of the solutions merged MyApp.exe.config file. This results in a executable that does not properly pickup configuration file settings not only because the file isn't named correctly but it also does not merge in target environment settings (ie. release, debug, etc.).
How do you have the Installer copy the merged MyApp.exe.config file to the Install Directory?
Try this, I believe this should work.
Select the config file, and in the Copy to Output Directory under File.Properties, choose Copy always or Copy if newer. You can choose any file you like with this method. Basically this file will be placed to a directory where the binaries are built. This is still a better method than configuring/fixing from InstallShield, I think. I will like to hear from you, if you disagree.
Another thing, a config file is used and determined at run-time by code. That’s probably the reason why InstallShield does not know the file dependency on it. And it is out of scope for that tool.
Have fun and let me know what happens.
Tommy Kwee
I am using SlowCheetah to do my app.config transforms and here is what we're doing to get installshield to work. For postbuild step, copy all files needed by installshield to a separate Install folder (i.e. copy "$(ProjectDir)$(OutDir)." "$(ProjectDir)bin\Install"). Point installshield to that folder to build it's output
I'm also using SlowCheetah for my config transforms, but the real answer to this question is that the InstallShield project pays attention to the selected Solution Configuration. If you select the Release configuration before building the InstallShield project, the Release output will be used in the install package.

Resources