Custom Uninstaller and App Manager

[Neville Lang]

Hi all,

When I deploy my VS2003-compiled app, it installs EXEs to the desktop side
and uses the ActiveSync AppMgr to install the CAB to the device. I also
control the deployment using an MSI file and have a custom installer and
uninstaller on the desktop.

After my app is installed, I have found that it can be Removed in two
places - i) the Remove button on ActiveSync's Tools -> Add/Remove Programs
and, ii) the Remove button for the app on the Add or Remove Programs on the
control panel. Removing my app using the Remove button on ActiveSync
(AppMgr) works perfectly as it has been setup to call my uninstaller via the
AppMgr INI file, and so things get tidied up on the desktop side as well as
the device side.

However, if I (or one of my customers) decide to remove my app using the
Remove button in the Add or Remove Programs on the Control Panel, the
removal process fails. I assume at this point the uninstaller has no
knowledge that the app was installed on the device via AppMgr and so the
removal from the device does not happen.

How can I prevent either i) the app from appearing on the Add or Remove
Programs list in Control Panel or ii) prevent the Remove button from being
operational on the Add or Remove Programs list and give a reminder to use
the ActiveSync Remove button instead? I will be interested to know how
others have got around this one when using MSI deployment.

Regards,
Neville Lang

 

[Ilya Tumanov [MS]]

You can remove "Remove" button from ARP, for example.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).

 

[Neville Lang]

Ilya,

Thank you for that clue - I will let you know how it turns out.

Regards,
Neville Lang

 

[Neville Lang]

Ilya,

I tried the "normal" way of adding the ARPNOREMOVE=1 property to the MSI
file but found that the resulting Uninstall key in the desktop registry (at
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{my app's GUID })
added the NoRemove Value BUT the process did not create the ModifyPath and
UninstallString Values when the NoRemove was added to the registry key. This
had the side-effect that the AppMgr Uninstall did not call my custom
uninstaller and so the desktop side was not removed.

I found that if I left the MSI "as is", that is , with no additional
ARPNOREMOVE=1, and manually added the NoRemove=1 to the registry key, where
the ModifyPath and UninstallString Values were on the list, everything
worked as expected. This seems like a better approach to achieve what I
want.

That only leaves the Change button on the ARP. For cases where I install a
CAB onto a device using AppMgr, can the Change button also be hidden?

If the Change button is clicked by the user, it pops up a Repair or Remove
option. Hiding this button would leave my app's entry in the ARP as a
secondary indicator that the desktop side EXEs have been installed, but it
would not have any buttons. That leaves the actual removal of my app, from
both the device and desktop side, to the ActiveSync AppMgr screen's Remove
button.

Regards,
Neville Lang

 

[Ilya Tumanov [MS]]

I believe you can edit dialogs in MSI to remove buttons you don't want.



However, I dislike the whole approach you're taking. I would consider device
and desktop completely independent with respective installers not caring for
each other at all.

For example, what if device is lost or stolen? How user supposed to
uninstall desktop portion then? What if migration from one PC to another is
needed?

User would have to remove device portion destroying all settings he/she
might have?

I would suggest keeping uninstall button and just show a message prompting
user to remove application from device as his/here convenience.


Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).

 

[Neville Lang]

Ilya,

Thank you for the clue on the buttons in the MSI, I will follow that up.

Thank you too for your comments on my installation approach.

When I designed my installer a few years ago, I wanted a "one-click"
approach for my customers who are scattered worldwide and are not corporate.
My custom installer therefore controls the installation of everything on the
desktop side as well as on the device. It is the device side where my users
become most familiar in their day to day use of my app. However, the desktop
is where interaction with a third-party app takes place. I have one icon
that a customer can use to download data from the third-party app, if they
have purchased that app in the first place. I use the upload of data from
the device to the desktop so that if the third-party app exists on the
desktop then when a user's device is "cradled" a message pops up asking
whether the user wants to perform a backup and merge with the third-party
app. I do not use ActiveSync for this but RAPI. For WM5, this process too
may change due to the limits on RAPI in WM5 Phone Editions.

Further, my custom installer (built for pre-WM5 o/s's) does not use the
AppMgr approach but relies on RAPI to perform the full installation. My app
then appears on the ARP and that is the only way to uninstall both the
device and desktop side.

This approach seems to be working smoothly for our customers. They do not
need to worry about installing two items - just one-click to do everything.
I like to keep things simple for them.

I do appreciate that there can be some issues that might crop up if the
customer either loses their device (so far this has not happened), if they
decide to replace their device with a newer one or if they decide to replace
their desktop computer with a newer one. So far, there has only been two
occurrences where these things did take place.

As per our recent discussions for WM5, I have modified my custom installer
to now use AppMgr for the installation onto devices using WM5, instead of
RAPI. The Pocket PC Phone edition devices seem to now block RAPI and so the
need for this change of installation. However, I decided to not touch the
older part of my installer for devices with an operating system earlier than
WM5. My new additions to the installer will only be for WM5 devices onwards.
So, the description above for using the ARP for uninstalling my app on both
the desktop and device side presently using o/s's earlier than WM5 still
applies. The newer approach will be for only for WM5 devices.

As stated on another one of my threads, this is the last patch update for
the current version of my app compiled under VS2003. I plan to issue a major
update (a v2) of my app in about 6 months time. That version will use VS2005
and CF2 and so, in that update, I will only have one method of installation
using the AppMgr. When I get to the installer design for that new version, I
will keep in mind your comments on this thread.

Thank you again for your replies to my queries.

Regards,
Neville Lang