Upgrade Merge module and its associated count
Posted 07 July 2005 - 10:42
(Sorry for my poor english but it's not my mother language)
I'm new in MSI Packaging and I want to do something which appears really difficult for me, so I need your help...
I'll take an example :
I have 3 *.msi file : A, B and C.
A contains : (A.personnal) files and (A.global_v1) files (global == merge module)
B contains : (B.personnal) files and (B.global_v1) files (B.global_v1 is the same module than A.global_v1)
C contains : (C.personnal) files and (C.global_v2) files (C.global_v2 is is an upgrade of global_v1, compatible with the global_v1 version, a driver for example)
What I would like to is :
If I install A -> B -> C, i have :
(A.personnal), (B.personnal), (C.personnal), and (C.global_v2). This point is not really difficult I think.
If I uninstall (C.global_v2) feature using the C.msi file (maybe because the new driver doesn't work well), I would like to replace the (C.global_v2) by the last version I installed (global_v1 in this example), and I want the merge module count to be updated !
I don't know if you caught me, if not, tell me :-)
Posted 07 July 2005 - 11:30
If you want all three applications to share the same file (from the merge module) then make sure you always install the file to the same location (like common files) and use the same component GUID (use a merge module). However uninstalling the application that installed v2 of the files in the merge module will not downgrade the file on the machine. It will simply unregister app C as a client of that component. When you also uninstall apps A and B the file will be deleted.
Posted 07 July 2005 - 14:05
|QUOTE (Stefan Krueger @ 2005-07-07 11:30)|
|However uninstalling the application that installed v2 of the files in the merge module will not downgrade the file on the machine. It will simply unregister app C as a client of that component. When you also uninstall apps A and B the file will be deleted.|
Could you precise this please ?
If I uninstall apps C, it will uninstall the merge module ONLY if the C merge module had a different GUID of A & B merge module ? (That's what I think)
I was thinking that different merge module (driver_v1 and driver_v2) HAD TO have a different GUID. But they can ?
Thanks for your answers !
Posted 08 July 2005 - 08:02
However if A, B, and C share the same component GUID and install the file to the same location, it will only be deleted if all three applications are uninstalled.
Posted 08 July 2005 - 12:14
I created an MSI file (A.msi) with its own files, and one merge module included. (version 1 which include 1 file and which writes the value "VERSION1" in a register key)
Then I created One MSI file (B.msi) with its own files, and one merge module included (version 2, but same GUID than version 1, which includes the same file as version 1 plus another file, and which writes the value "VERSION2" in the same register key than version 1)
When I launch A and then B, that's ok, I have all the files I want where I want to, and the register key has the value : VERSION2
When I launch B and then A, the register key has the value : VERSION1 !!!!
I don't undersand why, because in the InstallShield 10.5 professional software, I wrote 220.127.116.11 for the first merge module, and 18.104.22.168 for the second (in the General Information > Merge Module Properties > Version string)
If you have any idea :-)
(I tried to write versions in the File Table, but when I Build with InstallShield, It doesn't preserve it, and when i write it directly with Orca, apparently, it doen't work because I have the same problem with the Register Key replacement...)
I have maybe an idea : Should i use the KeyPath to identify a module by a special file ? (I don't know how does it work, but maybe you know)
Thx for your precious help !
Posted 08 July 2005 - 15:58
You could put the registry entry in its own component and make it the key path of that component. Mark the component as Never Overwrite. I think this would prevent it from overwriting an existing registry key. Note that this would also prevent it from overwriting "1" with "2".
Another option would be:
- Use a property as the registry value, e.g. [VERSION]
- As default value for MYVERSION specify the current version (in Property manager), e.g. "2" for setup B.
- read the existing entry (Systrm Search) and store the result in MYVERSION if it is greater than the version you are currently installing. E.g. use MYEXISTINGVERSION as property in System Search. Use a custom action type Set a Property to set MYVERSION to [MYEXISTINGVERSION] with a condition of MYEXISTINGVERSION > MYVERSION . This comparison will only work if your versions are integers (no dots etc.)
Posted 08 July 2005 - 16:38
I could be a solution.
But if my registry key only changes when, for example, files1.dll changes. I can associate the registry key intervention to the files1.dll version (putting them in the same component with files1.dll as keypath ?)
I have another question (if you have the time to answer to my newbs questions :-) ) :
I know that we can associate a keypath to ONE file (or registry key ?) of a component.
For example : I have a component COMPDLL with 3 files : 1.dll, 2.dll and 3.dll, with 1.dll as the keypath of COMPDLL.
I have package_v1.msi with COMPDLL (1.dll, 2.dll,3.dll).
I have package_v2.msi with COMPDLL (1.dll, 2.dll, 3.dll, 4.dll)
What will happen if I launch package_v1.msi and then package_v2.msi ? (I ask it to you because I don't understand how the MSI program will choose to update the component or not... does it only based on files versions ?)
Last question (of this post ) :
How can I replace *.INI (or *.txt) files which have the same name ? The problem is that *.INI files don't have a version number ! (?) So as you said, files will not be overwritten ?
Hope you'll understand my questions, it's not so easy to ask (in english) for something I don't understand very well.
A big thank for all your help !
Posted 11 July 2005 - 09:22
Existing non-versioned files (INI, TXT and the like) will be overwritten only if they have not been modified sinice they have been copied to the machine. If the modified date is more recent than the create date they will not be overwritten, assuming that the user has edited them and to preserve his work.
Posted 11 July 2005 - 09:45
I have another questions about non-versioned files :
CASE 1 :
In my first package, I create a component : READMEFILES with the file : ReadMe.txt (5KB).
The End-user opens this file, writes a comment, and saves it (so the ReadMe.txt file has been modified)
In my second package, I use the same component, with the file : ReadMe.txt (10KB).
(Names are the same)
According to your answer, the ReadMe.txt file won't be overwritten.
How could I overwrite the file ?
CASE 2 :
If, in my second package, I don't use the same component (so the GUID is different), what will happen ?
Thanks and good morning !
Posted 11 July 2005 - 09:58
In addition, case 2 is breaking the component rules (you should not install the same resource using different component GUIDs).
Posted 11 July 2005 - 10:32
I'm searching in the Component and File Tables (Attributes) but I don't find any option which could help me...
Maybe the solution would be to uninstall specific components (all the non-versioned components (files) for example) and to re-install them (even if its installs the same, I'm sure that these file are the last ones...).
But I don't know if MSI can rollback this if the installation fails...
What do you think about it ?
Edited by babric, 11 July 2005 - 10:39.
Posted 11 July 2005 - 16:05
Alternatively you can do "version lying" i.e. enter a version number for the file in the File table, even if it doesn't have one. This Windows Installer will think it's newer (any version is higher than no version number) and will overwrite the file. Note that it will do this every time, even for a re-install (repair).