2

I have an application that is deployed via ClickOnce to a network share. I have the install mode set to online only. The application runs in the system tray. In Windows 7, when the program is first ran, it will show up in the extended system tray (the one where you have to click on the arrows first to get to the item). The problem is that when a user sets their preferences to have the application show up in the main tray the preferences will get lost when I publish an update. Then my application will show up twice in the preferences (once for the old version which has it set to show in the main tray and another which is the new version which is not set to show up in the main tray. How can I get it to work so that they only have to set their preferences once to get it to show?

There is a similar question here: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/c33ab558-7fd5-4330-a985-9702358472d0/

skeletank
  • 2,880
  • 5
  • 43
  • 75
  • I've concluded that there is no way to get the desired outcome using ClickOnce. I decided that it was be easier just to deploy it using some batch files from a network share. That way the application always deploys to the same location and it will save their preference to show the application in the main tray. This works fine since this is just an in-house solution anyway. – skeletank Apr 01 '11 at 20:39

2 Answers2

2

This actually can be done (i.e. you can make Windows 7 recognize the notification icon as being the same one even though ClickOnce has changed the path of your executible during an update). It's just very finicky and requires that every single one of the below criteria are met with exacting precision:

  • Generate a GUID on your dev machine and set the guidItem member to it on every call of Shell_NotifyIcon. It must always be the same GUID, even between release versions of your app (kinda the point here).
  • Set the NIF_GUID flag on every call to Shell_NotifyIcon.
  • Digitally sign the assembly with an Authenticode certificate that will be trusted on the target machine (i.e., a real one).

If the settings are not being saved regardless of path -OR- Shell_NotifyIcon starts tossing false back at you, that means either:

  • You're making at least one call to Shell_NotifyIcon somewhere in your code that is not setting the guidItem member of the struct appropriately or is not setting the NIF_GUID flag.
  • You didn't really sign the executible binary. If you're using Visual Studio to do this, it's really bad about not telling you when signatures fail because of configuration issues. Check the properties of the file in Windows Explorer and ensure you can get to the tab that shows you the signing cert.
  • Your certificate isn't trusted on the target machine.

If you mess up at some point and Shell_NotifyIcon starts returning false and just won't seem to stop, generate a new GUID to start the process over again.

Also Note: Check the OS version to make sure you're on Windows 7 or above when ever you try to do anything concerning a notify icon with a GUID. Windows Vista and below will freak out.

Example:

var os = Environment.OSVersion.Version;
if (os.Major > 6 || (os.Major == 6 && os.Minor >= 6))
{
    lpData.guidItem = Guid.Parse("Your Own Guid Here");
    lpData.uFlags |= FlagEnum.NIF_GUID;
}
Daniel Henry
  • 856
  • 7
  • 18
  • Cool info. Though if it's that complicated - at that point I'd consider a launcher, i.e. one static executable name and location that persists between deploys, i.e. some other deploy method. – ubershmekel Sep 17 '14 at 18:50
0

We used to have a notifyicon for our application. Our problem was it wouldn't show it unless the user set all of the notifications to show all the time. If the user didn't run the app for a while, and then ran it, it would no longer be displayed until they used it several times.

I don't know of any way to work around this. We ended up taking it out for this reason as well as some business reasons.

RobinDotNet
  • 11,723
  • 3
  • 30
  • 33
  • We definitely need the notifyicon as this is an application for the user to change their presence info ('In','Out','Busy',etc.) and we want them to quickly be able to access a context menu and change their presence. – skeletank Mar 29 '11 at 12:57
  • Can you get them to set the notifications to always set up? I don't think C/O can do this itself, but if you could figure out how to do it programmatically, you can include an [exe] with the C/O deployment and do a process.start on it. You can't elevate privs on a C/O app, but the C/O app can process.start a new process, and THAT process can ask for permission to elevate privileges. – RobinDotNet Apr 01 '11 at 08:18
  • This seems like the only viable solution, other than not using clickonce, though I can't use it for my situation. – skeletank May 10 '11 at 20:04