Did some research online and it's been a lot longer since I have built a lot of installers than I thought! This behavior changed between versions 6.0 and 6.1! Sheesh...
I guess I didn't grasp the full importance of JP's post the first time I read it. In any case, as JP says you have to change the GUID in the builder--of course that means that you are now having to change the build file even though nothing has really changed. Apparently the key here is that the Microsoft Installer won't overwrite the old version unless the GUID is different. A pain in the rear, but according to the documentation I found, "correct behavior" never the less. Too bad someone hasn't come up with a way to fix this "correct behavior".
What was so wrong with the original 6.1 behavior where the installer would ask you what to do if it found the same GUID? Or for that matter, the GUID is a machine generated number right? Why should I even have to bother with it. Let the builder generate a new one for me each time I build the application. Logically, there would be no harm done, because if the application is a new version, overwriting the old one is what I want to happen otherwise I wouldn't be rebuilding the application, and if the application hasn't changed I am overwriting the file with another one just like it--again, no harm done.
And if there are edge conditions where it would matter, a simple check box in the builder would address that problem: "Automatically Generate New GUID". If it's checked it would do as I described, if it wasn't checked, the two existing couple controls would be enabled and you'd have the current functionality back. Probibly would take about 20 minutes to implement...
Mike...
