Breaking shortcuts on Vista
Posted 06 March 2007 - 17:39
For those that have read other threads about my shortcut woes please skip this paragraph. The problem I had was that Windows Logo testing for Vista dictates that no component may have more than one advertised shortcut... and that all shortcuts must be advertised. Ergo, components may only have one shortcut. So if you require a Start menu shortcut to your EXE as well as an optional desktop shortcut to your EXE you're a bit screwed. The solution I came up with was to create an advertised shortcut and include it as a file in a component of its own and give this component the additional shortcut. This is essentially a shortcut pointing to a shortcut, but it does work! And it passes Windows Logo certification, woo hoo!
However, having created a shortcut to a shortcut, I have just discovered that they break if your Vista user has UAC turned off. What happens is that the desktop icon, which points to an LNK file I've installed (an advertised shortcut of my EXE) installs fine and appears to be perfect. Then when you use it for the first time, it runs the app fine, but somehow Vista decides to change the shortcut... it loses 0.8kb in size, no longer displays the application's icon and is no longer a shortcut in its properties. Repairing fixes it, but not a useful solution.
Leaving UAC active stops this change from happening and the shortcut remains perfectly fine and intact... so I'm guessing that this is preventin Windows from editing the file, but not why Vista deems that the LNK file should be changed at all.
Posted 08 March 2007 - 18:31
|Windows Logo testing for Vista dictates that no component may have more than one advertised shortcut|
Instead of including a shortcut file in your setup, maybe you could copy the shortcut that your setup created to the Desktop.
Note that Desktop shortcuts are discouraged. Not sure if the are explicitly forbidden in the logo requirements though.
Posted 08 March 2007 - 18:52
|Is this really true? I don't see why.|
Nor do I, but my first package failed on a variety of points and this was one of them... I checked the documentation and was astonished to discover they were correct.
|copy the shortcut that your setup created|
Is this something the installer can do, or would you recommend a CA calling a DLL function? A solution of this nature had occured to me recently, but time didn't permit me to investigate it. Now this larger problem has reared it's ugly head and I may have to find the time.
Posted 08 March 2007 - 19:11
|There must not be more than one file specified per component as a target for the Start menu or a Desktop shortcut.|
But in my understanding this doesn't mean that you can't have multiple shortcuts to the SAME file.
Oh, re-reading your previous post, the problem is that you want to make the desktop shortcut optional, so it needs to be in a separate component.
But where in the logo guidelines does it say that all shortcuts must be advertised?
|Is this something the installer can do, or would you recommend a CA calling a DLL function?|
You will need a custom action. I think that neither DuplicateFile nor MoveFile tables can do this.
Posted 12 March 2007 - 12:34
The "Certified for Windows Vista Test Cases" document Test Case 29 says that you need to open Orca and check that no component appears more than once in the Shortcut table... so even if the Desktop shortcut wasn't optional, it couldn't be in the same component and so can't be advertised (unless you install the EXE twice!!)
Installing non-advertised shortcuts to potentially per-user locations (like the desktop) results in an ICE57 error that can't be satisfied without a self-repair for each new user running the application, which is not a nice experience. We discussed this flaw in the ICE validation last year:
So, having realised the potentioal for creating shortcuts to shortcuts getting around these limitations. I have now discovered that Vista changes thee shortcuts so long as UAC is disabled. Interestingly enough, it only effects shortcuts to LNK shortcuts, shortcuts to URL shortcuts remain intact and stable in any situation.