Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Per-Machine shortcuts


11 replies to this topic

Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 30 October 2006 - 13:11

Hi guys,

I keep finding myself going round in circles trying to satisfy validation errors in ORCA with the respect to non-advertised shortcuts. Any advice or comments of your own experiences would be most welcome.

1 - I have shortcuts optionally installing to the Desktop. Because they are an option, they can't be in the same component as the EXE they point to (can they?) and so are not advertised. This generates ICE43 errors... I don't understand why new users should get a 'repair' on run up for a shortcut they've got because ICE43 demands an HKCU keypath.

2 - Having given the shortcut the HKCU keypath as above, I start getting ICE57 errors because I now have a per-user keypath for a per-machine shortcut. The "DesktopFolder" is resolving to the per-machine location because Vista logo compatability insists on a per-machine install and I now have ALLUSERS set to 1 to acheive this.

3 - If I change the keypath to be in HKLM (since they are in a per-machine location) I also get errors in ICE38 because ORCA doesn't seem to realise that "DesktopFolder" is resolving to the per-machine location while ALLUSERS=1 (hard-coded in the property table) and thinks I have a per-user component requiring an HKCU keypath.

I can't see any method of creating non-advertised shortcuts as part of a per-machine installation without getting validation errors.

Is this really the case?

Regards,
Gareth

Edited by Gareth at Serif, 30 October 2006 - 13:12.


Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 31 October 2006 - 17:40

I've managed to overcome most of these errors by doing the obvious thing... I created the advertised shorcuts that are not optional and used that file as a source for the other shortcuts. So instead of creating non-advertised shortcuts I'm now installing LNK files in the same place(s).

This has stopped the requirement for non-advertised shortcuts from having an HKCU keypath, but the one file being installed to the [DesktopFolder] still gives the ICE38 error that I'm installing a component to a user profile and this should have an HKCU keypath.

Why doesn't validation use the ALLUSERS=1 from the property table to realise that this folder will resolve to the per-machine location and stop reporting the error?

Regards,
Gareth

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 31 October 2006 - 18:14

QUOTE
Why doesn't validation use the ALLUSERS=1 from the property table to realise that this folder will resolve to the per-machine location and stop reporting the error?

Because it's not that smart, and because you could always change the ALLUSRES setting from a dialog or custom action.

Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 02 November 2006 - 18:09

Thanks for your observations, Stefan.

Yeah, I thought about the possability of users adding ALLUSERS<>1 from the command line, but surely you can draw the same conclusion that command lines can edit any critical property that the intended UI wouldn't have allowed?

Even so, I have added component conditions for the effected components that ALLUSers must equal 1, else don't add these files/shortcuts at all. Still validation has no idea (but it's not too bright, as you say).

I'm gonna submit it for logo compatability as it is and see what comes back. I just hope they're bright enough to understand that the 'error' case can now never happen under any circumstance. I'll post back the results.

TTFN
Gareth

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 03 November 2006 - 10:16

If they start arguing, can you perhaps create these shortcuts with a custom action instead? Or even more dodgy; copy the *.lnk files in place?
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 03 November 2006 - 10:35

QUOTE
If they start arguing, can you perhaps create these shortcuts with a custom action instead? Or even more dodgy; copy the *.lnk files in place?

I wouldn't recommend this, if at all possible you shouldn't reduce the quality of your package to avoid a silly validation warning. However the test cases are pretty clear:
QUOTE
The application’s MSI package must not receive any errors in the Internal Consistency Evaluators (ICE) 1-24, 27-31, 33-36, 38-57, 59, 61-63, 65, 67-72, 74-84, 86-87, 89-94, 96-99 when validated in order to pass this test case.
...
Any errors that are received as a result of the ICE validation must be fixed. You can use ORCA to copy, paste and save results into a text editor such as notepad.exe for easy retrieval.


Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 22 November 2006 - 14:21

Okay, so I've had my application validated for Vista Logo and predictably, it failed. However, I worked on a solution that I think is quite untidy considering the power of MSI technology, but it does work...

What you need to do is decide how many shortcuts you're going to need; they could be URL or LNK type and install pre-made ones to a sub-directory of your main app - Something like, "[ProgramFilesFolder]\<Company>\<App>\<Version>\Shortcuts. If you want two shortcuts pointing to your main executable, perhaps in the Start Menu and on the Desktop, then create those as seperate LNK files (with an incremental suffix perhaps).

Being sure that each shortcut has it's own component, create advertised shortcuts to each file/component as part of the installation process, as options if desired. And now your app validates in ORCA without demanding HKCU keypaths for your per-machine shortcuts. Just to be certain, I have added "ALLUSERS=1" as component conditions so that anyone who modifies the property via commandline won't get in a mess.

Furthermore, while ORCA validation doesn't mind, Vista Logo will fail your app if you include more than one shortcut per-component... hence needing seperate files/components for shortcuts pointing ultimately to the same file.

Regards,
Gareth

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 22 November 2006 - 15:04

I'm not sure I understand.

As far as I know if I want two advertised shortcuts (e.g. one in start menu and one on the desktop) pointing to the same exe, they have to be in the same component - because advertised shortcuts always point to the key file of the component.

For non-advertised optional shortcuts that are in a separate component, can't you just use a HKEY_USER_SELECTABLE registry entry as key path? For a per-user install the shortcut would be on the per-user desktop and the registry entry would go to HKCU. If ALLUSERS=1 DesktopFolder would resolve to the per-machine desktop and the registry entry would be created in HKLM.

Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 23 November 2006 - 16:49

Hi Stefan,

Always good to read your expert overview. I like the idea of utilising HKEY_USER_SELECTABLE, but is that not unique to later versions of InstallShield? I can't find out how it relates to the MSI table from MSDN, which would give me a clue as to how to use it in my WiX projects.

Also, to expand on your first comment, Vista logo automatically fails any MSI database that includes more than one shortcut per-component. Until yesterday, I too had multiple advertised shortcuts in the same component in order to generate additional shortcuts to the executable. If you have MS's documents about Vista Logo, this is detailed in their poorly written Test Case 29.

Regards,
Gareth

Gareth at Serif

Gareth at Serif
  • Full Members
  • 85 posts

Posted 23 November 2006 - 17:40

Ah... I have found how to use HKEY_USER_SELECTABLE by delaring the Root in WiX to be "HKMU", this sets the root column in the registry table to -1 as documented on MSDN.

However, this still gives an error in ICE57:
QUOTE
Componet 'DesktopShortcut' has both per-user data and a keypath that can be either per-user or per-machine


It appears to be all too well aware that the registry entry can resolve to either per-user or per-machine locations, but not that the "DesktopFolder" property will do likewise depending on the ALLUSERS property.

Is there anyway around this? I much prefer this solution to mine, Stefan.

Cheers,
Gareth

Edited by Gareth at Serif, 23 November 2006 - 17:40.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 November 2006 - 18:04

QUOTE
It appears to be all too well aware that the registry entry can resolve to either per-user or per-machine locations, but not that the "DesktopFolder" property will do likewise depending on the ALLUSERS property.


To me this looks like the ICE needs to be fixed. Maybe you can talk to Microsoft about this. Not sure if documenting this in your test document would help.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 November 2006 - 18:22

You can avoid the ICE error if you use a HKCU key path. Sounds wrong to me, because with ALLUSERS=1 you'll have a mix of per-machine (all users desktop) and per-user (HKCU) data, but the ICE is happy.