Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Using DLL CA to edit the upgrade table


5 replies to this topic

Marius Blomli

Marius Blomli
  • Members
  • 5 posts

Posted 16 February 2006 - 15:50

I think I've searched the entire web twice for info on this, so I hope that someone here can help me out. smile.gif

I'm developing the installer for a product where we can't set the upgrade table at build-time. So to be able to remove the previous installation of the product, I have written a custom action that does a bit of registry searching and inserts an entry into the upgrade table of the running installation. This actually seems to work, using a bit of message box debugging I can see the custom action doing it's thing. The FindRelatedProducts action runs and sets the correct product ID in the selected ActionProperty. Everything seems to be running in just the same way as when I manually insert an entry in the upgrade table.

But then it falls apart. The RemoveExistingProducts action doesen't run. Relevant extracts from the log:

[...]
Action start 18:15:27: FindRelatedProducts.
MSI © (A4:EC) [18:15:27:265]: PROPERTY CHANGE: Adding REMOVEGUIDPROPERTY property. Its value is '{2EE5D018-1CE1-411F-9F72-2D95942C055C}'.
Action ended 18:15:27: FindRelatedProducts. Return value 1.
[...]
MSI (s) (0C:EC) [18:15:28:343]: Doing action: RemoveExistingProducts
Action start 18:15:28: RemoveExistingProducts.
MSI (s) (0C:EC) [18:15:28:343]: Note: 1: 2262 2: Upgrade 3: -2147287038
Action ended 18:15:28: RemoveExistingProducts. Return value 1.
[...]

I can't figure out why this action doesen't remove the previous installation. Everything seems to be set correctly but it doesen't work. Has anyone tried anything like this? I can't see any reason why this shouldn't be doable, but maybe I'm missing something?

If anyone can point me to some documentation on the format on these logs, I'd really appreciate that too, since I haven't really been able to find any. What does "Note: 1: 2262 2: Upgrade 3: -2147287038" mean?

luke_s

luke_s
  • Full Members
  • 532 posts

Posted 16 February 2006 - 23:12

When you can find some documentation that explains in detail the lines in the verbose log then please point me to them as well!

It looks like to me that the RemoveExistingProducts action has executed and finished without error because it returns 1.

- What is the value of REMOVEGUIDPROPERTY property just before RemoveExistingProducts executes? What are your attributes for the upgrade table column "Attributes".

- Have you added the REMOVEGUIDPROPERTY to the SecureCustomProperties property?

Is the log you have pasted below from a verbose setting?
If you are running with a verbose log, it should spit some more information out about the install it is removing.



Marius Blomli

Marius Blomli
  • Members
  • 5 posts

Posted 17 February 2006 - 11:30

QUOTE

When you can find some documentation that explains in detail the lines in the verbose log then please point me to them as well!


Will do.

QUOTE

It looks like to me that the RemoveExistingProducts action has executed and finished without error because it returns 1.


So it runs, but decides that nothing needs to be done, even if FindRelatedProducts has found the old installation. Why? What is the hidden, undocumented prerequisite required to make the action work?

QUOTE

- What is the value of REMOVEGUIDPROPERTY property just before RemoveExistingProducts executes? What are your attributes for the upgrade table column "Attributes".


According to the msi debugger, it is still set to the product id of the old installation.

I've tried a couple of different values for attributes, including 0, and 260. I think this run was made using 260. (Version min inclusive + ignore failure.)

QUOTE

- Have you added the REMOVEGUIDPROPERTY to the SecureCustomProperties property?


Yes.

QUOTE

Is the log you have pasted below from a verbose setting?
If you are running with a verbose log, it should spit some more information out about the install it is removing.


The log is run with /L*x. Running /L*xv only provides one more line of redundant information, like this:

MSI (s) (FC:B0) [14:57:23:359]: Doing action: RemoveExistingProducts
Action 14:57:23: RemoveExistingProducts. Removing applications
Action start 14:57:23: RemoveExistingProducts.
MSI (s) (FC:B0) [14:57:23:375]: Note: 1: 2262 2: Upgrade 3: -2147287038
Action ended 14:57:23: RemoveExistingProducts. Return value 1.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 18 February 2006 - 10:30

CODE
MSI (s) (FC:B0) [14:57:23:375]: Note: 1: 2262 2: Upgrade 3: -2147287038

mean that there is no entry in the Upgrade table.
I notice that your FindRelatedProductes log portion is from the UI sequence (client side) while the obove is from the Execute sequence (server side) which is where the actual removal happens. I guess that your temporary change to the Upgrade table isn't forwarded from the client to the server process. Try inserting your custom action to the Execute sequence, too.

Marius Blomli

Marius Blomli
  • Members
  • 5 posts

Posted 20 February 2006 - 09:20

Fantastic!

That solved it. It seems I need the action in the UI sequence for the FindRelatedProducts to work and in the execute sequence for the RemoveExistingProducts to work. Slightly nasty, but if that's what it takes...

Thanks a lot to both of you! biggrin.gif

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 20 February 2006 - 20:22

It's no unusual to have the same action in both sequences.