When I use an MSI to install an application it registers all files that must be remove. But if in a patch I need to add new files, those won't be removed on uninstall. How to make this to happen?
One way I thought was to modify the MSI to remove the folder even if there are files present. But this will only affect new installations, not existing ones.
I also tried to alter the Windows Registry, to include this new file in the list of files to be removed. But it didn't work.
Changes made by a patch should also be removed if you created the patch correctly. How do you create your patch? Do you follow the patching rules from Microsoft?
Related
I have a Visual Studio Setup project which includes a .SQL file from my project which should always overwrite the existing file if I run the installer on the same machine to update to a new version. The problem is that doesn't always seem to happen. Under File System > Application Folder > File Installation Properties, which property would tell the installer to always overwrite the existing .SQL file on an install?
The upgrade is an install of the new files on top of the older files, during which file overwrite rules are followed. The rule for data files is that they will not be overwritten if they've been updated since they were installed. If you've installed a database that's now full of customer data it's usually a bad idea to just replace it with a new empty database:
https://learn.microsoft.com/en-us/windows/desktop/msi/neither-file-has-a-version
Among the ways to solve your problem are:
Update the existing file with the new data using a custom action.
Avoid the problem in the first place by having the installed file copied to a location where it can be used, updated etc by the application. The original can then be overwritten by the upgrade, and the application detect that there is a new one to use, that it copies to replace the previous copy. It maybe too late for this.
Have the application make the creation date and modify date of the file have identical values so that the upgrade will think it's not been updated.
Install the new file to a different location (and use 1. from now on). The older file will be removed by the upgrade.
Edit the MSI file (with a tool like Orca) to move the location of RemovePreviousVersions (in the InstallExecuteSequence) so that it is immediately after InstallInitialize. This will completely remove all of the old files before installing the new ones, so it won't help if you have that database full of customer data mentioned in the opening paragraph.
I have a fully functioning NSIS installer and it works great. However, I have just been asked if I could amend the installer so that if any file I install is changed, it is not removed by the uninstaller.
At first glance there is no obvious solution apart from writing the installed file paths to the registry along with their time-stamps, and then checking this information via the uninstall code, removing only the files that have not had their time-stamps updated.
Is there any existing NSIS script/plug-in I can use to do this or anything obvious that I am missing?
Thanks for your time.
Yes, you would have to store the modified timestamp or file hash (MD5 etc) in the registry or a .ini file during install and compare in the uninstaller...
I am developing a package using Installshield 2008 Primer Edition and Project type is Installscript MSI project.
The problem I am facing is during installation I am installing some of the files to the following location C:\Program Files\Company\SystemFiles from this location I am copying and adding the set of files into System32 folder, it contains DLLs and OCX files, copying into the System32 folder has been done using Installscript.
Due to this during uninstallation, the installed file is getting removed from System32 due to this other dependent application which requires the same set of DLLs have stopped working.
I have approached Installscript to copy files from ProgramFiles to System32 Folder rather than using built-in options because we have an issue during the upgrade in order to avoid that I am using Installscript.
Even I have tried several workarounds like setting the file attributes after file copies to System32 using Installscript like FILE_ATTR_SYSTEM which sets the system attribute but still files are getting removed during uninstallation.
Any idea how to give file attributes as PERMANENT or SHARED; will this help, and if it will, then how can I set it using Installscript?
I have 2 ideas
1)I think you can use SHARED option as this wont remove the files while uninstallation.
2)Also when i was facing similar issue , what i did was putting all the required files in the installation directory itself so that while uninstalling only the installed files will be removed.(I know this is not a best solution)
(NOTE:I have worked on Install shield some 6 years back and so remember only certain things)
You can also disable logging from Install Script. This will make the installer "forget" that it installed specific files groups or features.
You should make sure to enable logging once again after you have copied the files that you want to permanently leave on the system.
If you don't remember to enable logging after you have disabled it, your uninstall process may not work correctly.
Syntax is as follows:
Disable(LOGGING);
//Add code to copy your permanent files here
Enable(LOGGING);
For InstallScript projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Uninstall" property in the right pane to a value of "No."
For MSI Projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Permanent" property in the right pane to a value of "Yes".
I see this is an old question but I just came across this. Seems to be a common problem. One good solution is to stage the files to a private directory mostly program files and then have a custom action do the copy and register (ocx etc). Installshield remembers what it copied so it tends to remove them. Do not disturb anything else like logging (my recommendation). Set conditions on the custom action so that it doesn't run during Uninstall.
Although sometime back I did another weird implementation which only programmers are used to doing.. Packed the files as resources and created my own code to extract and deploy (Something that Process Explorer kind of tool does). There were certain use cases that warranted this kind of implementation. But again this is complicated and obviously reinventing the wheel. Unless you are good with C/C++ and Windows API this would be difficult. I would still suggest you stay away from this kind of implementation because it is also considered a "virulent behavior". Yet, so far I never got warnings from the Anti-malware products.
I've got a Setup & Deployment Project in VS2005. One of the files that i'm installing is a SQLite data file.
I'm about to release a new version for the software, but i found that if i run the update on existing installation it overwrites the data file.
I've got an updated data file in the setup project so it's newer than already installed, but i don't want to overwrite it.
I've tries setting the Permanent property for that file to True, but to no avail.
Any suggestions?
Ok, here's a workaround that i've used:
In my setup project I've renamed my blank database file from Database.db to Database-blank.db.
In my app i'm checking if Database.db is missing and copying Database-blank.db to Database.db if it is.
then just load existing Database.db
This way i can ensure the local copy of the data file (Database.db) does not get replaced by newer versions of the software.
In MSI, the best way would be to make a record in the Upgrade table, determining whether this is an upgrade installation, and setting a property if it is. Then put the data file in a component, and place a condition on the component. Alternatively, make an entry in the AppSearch table, checking for the presence of the file (through the DrLocator table).
I don't know whether a Setup & Deployment project supports any of this. So as a fallback, install the file with a different name, and then create a custom action that copies over the file conditionally.
Because VS2005 setup when upgrading a program first it remove the original installed instance
and then install a new one, so for that the file will be removed every time.
to avoid replacing or overwriting the file I suggest the following:
1- mark the file as readonly in the setup project.
2- mark the file as permanent in the setup project.
now after upgrading the file it will not be overwriten, but your application can't deal with this file because it's readonly, so in the startup of your application check if the datafile is readonly uncheck it.
I want to make a installation which can be both new installation and update installation.
When it was used as an update installation, I want some files to be updated regardless the version and modified datetime. And some files would never be updated.
What I tried:
Set the "REINSTALLMODE" to "amus". And set the "Never overwrite" property of never updated files' components to be "Yes".
What I get:
It doesn't work. Those components with "Never overwrite = yes" are still updated somehow.
My question:
Is this right? REINSTALLMODE has the higher priority than component's "Never overwrite" property?
How to deal with this partial updates issue?
Thanks in advance.
MSI has specific File replacement logic (Archived link).
I would look into doing a Major upgrade.
Assuming these are unversioned files (for example text/xml config files, not assemblies) I would manually set the File Version on any file I wanted to always be updated (the manually set version will override what is already installed), and leave alone the others which the file replacement logic should ignore.
Here is a doc about REINSTALLMODE=amus which mentions the 'a' means ignore file versioning rules and update everything. not what you want. Also, I believe REINSTALLMODE is generally for 'repair' operations, not install/upgrade anyways.
We do something like this...
Install files to program files
Install default configuration to all users appdata
Copy default config to per-user appdata if per-user config not found.
What this means is that if an update is applied, the default configuration is reset but the per-user configuration is not. All settings, etc are saved and not overwritten during the MSI update.
Depending on what files you're trying to "not update" I suspect you can probably do something along similar lines.