I have several files failed to update in windows installer patch. They are dynamic link files， with file hash changes， but the MsiFileHash table “File_" has changed for each file, below is the same file in MisFileHash table:
RTM fileA:_A0FB2DAA62D356E1B64EA457014BA886 0 543212956 662074909 -1730111711 -2096793600
Patch7 fileA: _490DC427E0D9E512E96D3E9BF2B317C7 0 -1371102532 -401194406 -232195904 525972747
Maybe this causes the update failure.
So I ask, will any way to force the dynamic link component to update in patch?
Thanks
A common reason for this is that the patch broke the component rules (for example by removing a component). A verbose log of the patch install would say something about SELMGR and component removal not supported. The patch update would go into advertised mode and fail to update anything. It would be useful to post the verbose log anyway to see if there is an entry about file replacement and whether an attempt was made to replace it and what it said (and this won't be there if component rules were broken).
The other issue is more obscure but is likely to cause problems. The primary key of the MsiFileHash (File_ field) table has changed. This implies that other primary keys in the new MSI have also changed. This is relevant:
https://blogs.msdn.microsoft.com/windows_installer_team/2007/03/07/arbitrary-labels-used-as-primary-keys-must-not-be-changed-between-versions/
but the bottom line quote from there is what matters " It’s imperative that the primary keys are not changed between versions of the package. " and that's because the MSI is a relational database and changing keys in different versions of the product will lead to unpredictable effects.
There is no indication of what tool you are using to create the patch, but most of them don't typically cause either of these issues because they build the patch taking account of the structure of the RTM and the rebuilt MSI file.
Related
We are working on Joomla3.9 project, have different environments and are using git as vcs. So every developer works on is own branch. It would be nice to have a database compare function like in TYPO3 or Contao (see the database differences after updating the project and apply the database changes just by one click). Or like the laravel migration system.
Any developer should easily update his own lokal database after database changes where made due an extension update via backend or by another developer. And of course the staging or live system must be updated easily too. We don't want to execute sql-scripts with the changes in phpMyAdmin.
We have tried https://dbv.vizuina.com/ . This is not the 100% solution. Like there is no cli support to start the migration process by an update script on the server.
Does anyone have a solution or knows an extension that can solve this problem? Or can this be handled with core Joomla functions (maybe with a little adjustment)?
So far, I've seen three possibilities to execute modifications to one ore many extension tables
1: Use the extension - revision control in the schema table. So add a new sql-file with an increased version number compared to the version number in the schema-table for this extension. Increase also the version in the manifest.xml and zip the extension again.
Reinstall the extension via extension->manage->install. So the new sql-file with the increased version number will be executed.
2: like the point above, but install the extension via joomla update mechanism (update server).
3.: create a new sql-file in sql/folder of the extension. No version name is needed for the new file, just update.sql oder another filename. Execute this script in script.php in update()-method, after the extension is installed (in this case it's an update) again.
The third possibility might be interesting. It should be possible to trigger the update()-method with a cli command / function, so that the method can be triggered via a script on the server.
But how can I get the info, which update-scripts have already been executed? Let's say I have 3 update files in sql-folder. update-1.sql, update-2.sql and update-3.sql.
update-1.sql has already been executed. So I don't want to execute this sql-file again - only the other two.
The schema-table is only used with the first two options. Do I have the info somewhere or must I manage the infos which update-scripts have been executed myself?
The answer related to versioning database for extensions depends on whether these extensions are tightly coupled to the application or need to be reusable to other applications also.
The latter case normally means that each extension accesses its own custom tables, in which case you should keep separate versioning for the database than for the extensions.
App version history can be kept in a db_version table. Then an insert statement is added at the end of each update script (adding an incremental version number). e.g.
insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');
Provided that you need to apply data migration on extensions also, you need to maintain a db_version_extensions table which keeps version history for each of the extensions separately. e.g.
'001' 'extension1','Mandy.Aguilar','initial version'
'002' 'extension1','Mandy.Aguilar','adding extra column'
'001' 'extension2','Edna.Potter','initial version'
'002' 'extension2','Elvira.Townsend','dropping unused table'
..etc
Each extension zip should keep initial creation script and all sql-update files(which should normally not interfere with the rest of the app tables).
After pull it will be relatively easy to execute all the scripts with filename version greater than the last version number written in the database. This should be done for the app and for each extension separately.
Now if the extensions are tightly coupled to the app, it means that they might be using/updating tables of the app. For extensions of this type, you can add the updates as part of the application updates. These extensions could even be developed at the same repo, and be kept as directories instead of zip files.
Not sure if joomla supports any tools for automating the process of performing incremental db updates, but a nice tool is flyway, with ports for command-line, maven and graddle. See: how does flyway work
I'm currently working with InstallShield to deploy a .NET Winforms app. I am new to InstallShield and have not enjoyed the learning curve. The Winforms app has three related DLL's which are not getting updated during a minor upgrade. For a minor upgrade I am changing the version from 1.0.001 to 1.0.002 for example. The package code is being changed for each build automatically.
I have tried adding the dll's to the [INSTALLDIR] and setting the property to "always overwrite". For some reason this causes the upgrade to also not update the main exe.
Tried changing the product code to force a major upgrade. This installed a new version alongside the old version, but the new version still had the old dll's.
Tried changing ReinstallMode from "omus" to "vomus". This had no effect at all.
Tried using REINSTALL=ALL, REINSTALLMODE=vomus. This did not update the dll's and also caused new installs to fail with message that application "is not marked for installation".
Tried changing the version from 1.0.00x to 1.1.00x. dll's still not updated.
I notice that when I view properties of these dll files, they have File Version = 1.0.0.0 and Product Version 1.0.0.0. Do I need to manually increase these versions in order for InstallShield to recognize that they have been updated?
Use one component per file and set each file to be keyfile in its own component. This avoid all sorts of component referencing and file replacement issues. Be aware that multi-file assemblies must share the same component as they are intended as one "atomic" file system unit.
In addition you must also increment the version number for each build or set REINSTALLMODE to emus instead of the default omus. Never use amus.
My advice: go with the file version updates - it is much more reliable. Like you state the File Version is used, it must be incremented. I like to auto increment the build version number (last digit). It has been a while, but I think you just replace the number with * and it auto increments. I think you can do this from the Visual Studio project property view.
Maybe read up on the file versioning rules as well. Essentially versioned files are version compared, and for unversioned files the create and modify date stamps are compared and the file is replaced if it is unchanged on disk. More sample info.
Remove the "always overwrite" flag you enabled for all the files you enabled it for. This flag may work poorly with patches if you ever need them and also with other features.
When a major upgrade creates two side-by-side installations it hasn't worked. What you are left with are two different products installed at the same time. There is good inline help in Installshield itself with regards to how a major upgrade is set up. Which version of Installshield are you using? The version bundled with Visual Studio may not feature this help material.
A note on major upgrades and "reverted files":
A warning on a classic major upgrade issue: be aware that changed, unversioned files not set to be permanent on original install may be uninstalled during a major upgrade and then reinstalled yielding the impression that they have been replaced, but they are actually deleted and recreated. These are typically important settings files like XML files or similar - and people struggle with this issue a lot. Major upgrades are essentially a sequence. The old product is uninstalled, and then the new one is installed or vice versa. In the former case the files may be uninstalled first and then recreated. This does not happen in the latter case if component referencing is done right because the files that are matching between products are not uninstalled, but retained and then overwritten if need be (according to the file replacement / versioning rules).
I have an InstallShield InstallScript MSI project that contains the FLEXnet Connect without Software Manager merge module. The version of this product is 6.0.32. I created a second installer for version 6.1 that also contains the FLEXnet Connect without Software Manager merge module. When I perform a major upgrade on a system that contains the 6.0.32 version I get a message in the MSI log stating:
Disallowing installation of component: {FF970098-B748-427B-B946-AA8E1A1F82AD} since the same component with higher versioned keyfile exists
The component is referencing the isusweb.dll file located in the FLEXnet Connect folder.
It looks like this check occurs prior to the 6.0.32 product being removed. The install proceeds to remove the 6.0.32 product, which removes isusweb.dll. During the 6.1 install the isusweb.dll is not put back because of the component version check.
The upgrade succeeds. When I attempt to run the application from a shortcut it verifies the components. Since the isusweb.dll is missing the MSI attempts a repair, then cannot find the MSI and does not allow the application to open.
Is there some way to get the merge module to always overwrite?
This sounds suspiciously like this bug:
http://support.microsoft.com/kb/905238/en-us
and I've come across this bug and you do see that log message, and RemoveExistingProducts is early in the install. It decides to not install the file based on the higher version being there, but doesn't re-evaluate that decision after the REP removes it. Then a repair restores it when you use a shortcut. The bug should apply only to files in the GAC or SxS, so that's a bit puzzling.
If you can schedule REP at the end of the transaction sequence (InstallExecute, REP, InstallFinalize) that should fix it - might be worth a try, all other effects of the move being ok.
Merge modules don't get installed, they get merged. Product MSI's get installed. One of the problems with using third party merge modules is if they have a bug, there isn't much you can do about it.
I'd consider creating an MSI solely for the purpose of encapsulating this MSM. Then I'd create a setup prereq or suite installer to install this MSI apart from your product MSI.
You have got two really good answers already, but to try and synthesize:
It really sounds like a buggy merge module. Phil suggests to fix your REP placement in the InstallExecuteSequence to work around the bug. Chris suggests to put the faulty merge module in its own setup. I agree with both and think you should follow both suggestions:
Remove the merge module from your main setup.
Create a new setup and add the faulty merge module and ensure the right REP sequencing.
For the REP fix to work your component referencing must be 100% correct - now and in the future. To eliminate this as a problem creating a separate setup allows you to contain the buggy module inside its own MSI. This will help you avoid re-activating the bug by mistake or by changed design in the future - and the latter is never unlikely.
As Chris says: a merge module isn't delivered, it is merged. An updated merge module may be available for all I know, but even then it is wise to contain it. Especially when you are dealing with the GAC (Global Assembly Cache).
Another solution that I applied when encountered this bug was to set to update the "Version" column from File table, in the merge module, using Orca. Set that to the maximum 65535.65535.65535.65535, this will force the upgrade to always install the DLL from the merge module.
in our company we use tfs for source control of sql database version,when developers change the database they generate Equivalent script and put it in sql tfs project and checked in it with related workItem.after build we generate patch with this script for clients,but before pacth we need to some one decide on priority of checked in script,now i want to this decition become automatic and my question is how could specified priority in the moment of check in?
Sorry for my bad english,if you want more informationn to answer let me know.thanks.
Version handling of databases seems to be a never-ending problem. At a previous client, we gave the databases version properties, and then stored patch scripts in folders for each version, e.g. "Patches/2.0.10", "Patches/2.1.0". The patch scripts could then be executed in the same order as they were checked in (creation date).
Upon release, we ended up generating a complete patch script consisting of all those separate patches merged together (since the patches often affected the same data, they could be optimized) along with a new version number, allowing us to record what version any given databes instance had.
So I am continuing testing and releasing changes to my app and I have come across a pain point that I am unsure how to deal with.
First off, my app uses a SQL Server CE database to store information and I need to be able to make changes to this db so I've created an internally updating process that runs whenever the application runs to make sure the db is up to date.
The crux of this internal update process is another SDF file named DBUpdates.sdf that contains all of the db schema changes that need to be applied.
The problem I am having is that the MSI distribution I created will not overwrite this file. It appears that when SQL Server CE opens this file, it changes the Modified date/time of the file. This is a flag to the MSI process that the file has changed, and that it shouldn't overwrite the file. Well now I am seeing that my db changes aren't being applied, because the MSI process thinks the user has changed this file.
At this point I am kind of stumped. I was planning on using an MSI distribution but maybe I can't. What do you think?
What about storing your .sdf as an embedded resource in your executable, and then extracting it to a temporary location on disk (as necessary) and perform the updates.
Unversioned files with MSI can be a bit difficult to handle if you need to force the installation of the file. You can see this previous question, for some ideas, How to add a version number to an Access file in a .msi.
The question contains a link to this blog post, http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx, which suggests the way I prefer to deal with this problem. Add the .sdf file to be part of your executable's component. The downside to this is if someone delete the .sdf file, but not your executable I don't think a repair of the application will catch this. If your using Visual Studio to create your MSI files then this may prove a difficult solution to implement. I strongly suggest your check out WIX in that case. It is a better MSI build system.