>Wolfgang,
>
>>>If it is an update (which replaces the existing installation), say, an
>>>update from 10.0 to 10.1, then don't use a separate Product GUID.
>>>
>>
>> what happens if we do?
>
>from the technical point-of-view, you register a NEW application (product)
>with Windows. It will create a separate uninstall entry in the Program and
>Features panel.

Hm

Hmmmmmmmmm

Hmmmmmmmmmmmmmmmmmm

Lets say, I have a program version 5.0.

Now I publish this program as version 5.1.

For existing installations, I want to provide an "update-installer", which
lifts the existing installed version 5.0 to version 5.1. This
"update-installer" does not contain any table, which is individual to the user,
like licence, but also that daily work stuff (Bewegungsdaten, whatever this is
translated into english).

They all have to have the same GUID?

I know that it a clumsy and pedestrian way to have a separate
"update-installer" to avoid overwriting existing data, because in SB I can
exclude all those files from being replaced. But in the past it happened that
admins made mistakes on their side, blaming it was my fault. So I separate
these two installers, with the result that the programs from the
"update-installer" are not able to run, if not installed over the existing and
licensed version. (Maybe I have to rethink my strategy).

Work could be so easy without customers....

Regards,
Wolfgang Orth
www.odata.de

Please note:
From time to time it happens, that I overlook a reply to my postings.
Please don't be angry.
In case of an emergency, try to contact me via mail.

Bitte beachten:
Von Zeit zu Zeit passiert es mir, dass ich Antworten auf meine Postings übersehe.
Bitte nicht böse sein.
Im Notfall bitte Kontakt per Mail versuchen.