I've been developing a way to automatically update the tray notifier of my developers whenever a new version of TeamCity server is rolled out.
It's based on a Powershell script that will be configured as a computer startup script, that will check if tray notifier is installed, check it's version and compare with TC server's version. If there is the need for updating it will update the tray notifier directly from the server, thus simplifying updates for unpriviliged users.
However I'm having problems with the way tray notifier works on windows registry level.
From my gatherings when you install the software it will create a key at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JetBrains\TeamCity\WindowsTray (64 bit arch obviously), which I am using to determine the software's version and compare it with TC server.
What seems to be messing all up is the fact that when the software is configured by any user, these configurations are stored in a key at HKEY_CURRENT_USER\Software\JetBrains\TeamCity\WindowsTray (why in the 64 bit hive instead of in the 32 bit one like previously?).
Now, when my script runs, it will check with HKLM that the software need updating, update it, but wait... the software update will only change the ServerVersion value in HKLM key and leave the HKCU one not updated. This way whenever the user runs the software it will report it's out of date, and can be confirmed by the About dialog (just for kicks you can go to ServerVersion value and change it to 9.0.0 for example!), even dough the binaries have been updated.
I've tried even to manually uninstall the client and then reinstall it. Same behaviour...
JetDev's, is this by design? If so why? Doesn't seem much logical to have the version values in several places that aren't all affected by upgrades. Any ideas on workarrounds or fixes about this?