12 replies to this topic

[babric]

Hi,

(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 :-)

Thx

[Stefan Krueger]

Merge modules are no different than regular components. If you wish to install and uninstall then independently (side-by-side) then make sure each is installed in a different directory and uses a different component GUID (basically it may be better not to use a merge module in this case).

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.

[babric]

[Stefan Krueger]

If C includes a component with a different component GUID (that's not the merge module GUID but the component GUID) to a different location than A and B, then you can also uninstall C independently.
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.

[babric]

Ok, I think I understand what you mean, but look at this please :

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 1.0.0.0 for the first merge module, and 2.0.0.0 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 !

[Stefan Krueger]

The version of the merge module has no effect at runtime. Only file version do have an effect. So your v2 files will not be overwritten (downgraded) by the v1 files. But there are no version numbers for registry entries.
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.)

[babric]

I think I understand what you mean (even if I never used comparisons... :-/)
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 !

[Stefan Krueger]

You should not have multiple DLLs in the same component. Instead place each DLL in a separate component.

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.

[babric]

Yes, you are right, the best way is to place each DLL in a separate component.

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 !

[Stefan Krueger]

Assuming that these ReadMe.txt file are installed to the same location (same directory) it will not be overwritten in both cases (file overwrite rules apply on a per-file basis).
In addition, case 2 is breaking the component rules (you should not install the same resource using different component GUIDs).

[babric]

There is no options or bits to set to overwrite this file ? (without breaking MSI rules of course)

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.

[Stefan Krueger]

You can add the file in question to the RemoveFile table. Thus it will be deleted before the new file is installed.
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).

[babric]

Thx a lot for all your answers.

I will please you to continue to help me HERE if you want, because we are now far away from what it is written in the topic title... :-)

Thx and see you in my other topic !