View Full Version : duplicate desktop icons when logging on as new user

06-28-2007, 03:52 AM
When I install our app a single desktop icon appears as expected. Icons also appear under the Start menu.

When I log off the administrative account and log back in as a standard user account the single desktop icon appears. When I click on the desktop icon to run the app the MSI engine starts, prompts for the media, and then creates a duplicate icon ... this time under the User's Desktop folder. The original icon was placed under the All Users' Desktop folder.

How can I prevent the icon from being installed to the User's Desktop folder.

I have a single Desktop Shortcut object in my setup.
It is associated with a single component which also includes the Start menu icons.
The start menu icons do not have this problem, just the desktop.
Below is the single row from the Shortcut table that describes this object.
AppDesktop, DesktopFolder, XMAPED5|DeLorme XMap Edit 5, ApplicationShortcuts, [INSTALLDIR]XMapEdit5.exe, NULL, "Description", NULL HOTKEY, NULL ICON, NULL ICON INDEX, 1, NULL WkDir, NULL DisplayResourceDll,

This is not an advertised shortcut. I had previously tried to associate an advertised shortcut with a DIM file but InstallShield sets a file as the keyfile when processing DIMs and that causes ICE43 errors.

06-28-2007, 09:22 AM
Has anyone else ever seen behavior like this? It seems to happen for anyone who is not the person who installed the app.

06-28-2007, 09:53 AM
Is this installation being performed with ALLUSERS equal to 1?

If not, I believe that would explain this behavior.

06-28-2007, 10:33 AM
The log file reports ALLUSERS = 1.

I am trying a different approach. I bet when I log under a different user that the value of DesktopFolder is being redefined even though ALLUSERS = 1. Therefore it does not think this part of the component is installed.

So, I am using SHGetFolderPath to get the value of:

#define CSIDL_COMMON_DESKTOPDIRECTORY 0x0019 // All Users\Desktop

as is defined in ShlObj.h. I believe that DesktopFolder is being defined as CSIDL_DESKTOP 0x0000 which is not the AllUsers desktop folder. My approach that I am testing right now is to create a custom directory called COMMONDESKTOP | TARGETDIR | . in the directory table. I then assign this as the _Directory foreign key in the Shortcut table. When my custom action runs and I find the value I then update the COMMONDESKTOP using MsiSetProperty.

06-28-2007, 11:59 AM
Well, there is still a problem and I am not certain what to do about the problem.

1. SHGetFolder - when I call the function it returns the correct value.
2. I noticed that just before the function is called that I get the following msg:

InstallShield 12:29:23: ProductCode is {55BC9FA0-591C-4B0A-A744-B75F204FA6CB}
MSI (s) (54!30) [12:29:23:171]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.

3. I am not certain why ALLUSERS is being deleted. Is this something that happens when running as a standard user?

4. Later in the script, when the shortcut is written the following lines appear.

MSI (s) (54:B0) [12:31:48:703]: Executing op: SetTargetFolder(Folder=16)
MSI (s) (54:B0) [12:31:48:703]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\winxpuser\Desktop
MSI (s) (54:B0) [12:31:48:703]: Executing op: ShortcutCreate(Name=XMAPED5|DeLorme XMap Edit 5,,,FileName=C:\Program Files\DeLorme\XMapEdit Internal\XMapEdit5.exe,,,,,,ShowCmd=1,)
MSI (s) (54:B0) [12:31:48:718]: Executing op: SetTargetFolder(Folder=2\DeLorme\XMap Edit 5\)

Based on the above lines I can make the following assumptions:
Folder=16 SHOULD be the common desktop folder per ShlObj.h define.
The value returned though is the %USERPROFILE% value from HKCU instead of HKLM.
The value I set in my custom action seems to be ignored completely when the shortcut is created!

Sometimes Windows just gives me fits *twitches uncontrollably*

07-02-2007, 11:28 AM
What was the action that was running when the ALLUSERS property gets deleted (look for an "Action Start" message)? This could help in isolating where/why the property is being deleted.

Since the ALLUSERS property is undefined at the time the shortcut gets created, the behavior seen with the SHGetFolderPath resolution of DesktopFolder would be expected. I'm not sure why it's not installing to the path set by your custom action. If your custom action is sequenced after CostFinalize, you should use the MsiSetTargetPath API instead of MsiSetProperty. If it is sequenced before CostFinalize the action should work with MsiSetProperty.