8 replies to this topic

[Pizzero]

I would like to ask, if there exists a method that allows to write user-specific registry entries for all Users of a system, so that any logged in user can read this values under his HKEY_CURRENT_USER key respectively after installation.

The reason, why I need to do this: I have a per-machine installation (a true per-machine installation, installing network components, etc.) which also uses the InstallShield Access97 Object. This object unfortunately writes also user-specific registry entries to HKCU, so that the Access97 only works for the (administrator) account, used at installation time (obviously per-user). When manually installing the missing HKCU-registry keys for other user accounts, the whole installation works perfectly for them, too.

As users can be added or deleted after installation, too, an approach as used for shortcut installation would be nice. When installing shortcuts in a per-machine way for all users, they are copied to the "All users" profile, with the great advantage that no system instance has to install or uninstall shortcuts, when users are added or deleted from the system. Does something similar exist for HKEY_CURRENT_USER registry entries as well?

Thank you!

[Stefan Krueger]

Missing HKCU entries would get created by auto-repair when the application is launched from an advertised shortcut. See "How do I add HKEY_CURRENT_USER registry entries to all profiles?" at http://www.msifaq.com/a/1011.htm

Maybe you can install the Access object per-machine by passing ALLUSERS=1 to it? (I'm not familiar with InstallShield's Access object)

[Pizzero]

Thanks Stefan! Great - that's the perfect solution for HKCU installation!

I have one more question, because in my old installation I used localized shortcuts (with different entries in the name column, linked 1:1 with corresponding components) and different dummy-registry entries used as keypaths. (The components/shortcuts have been created automatically by the Access97-Designer-DLL of InstallShield.)

The shortcuts used one single (non-advertised), fixed target. The target (msaccess.exe) was installed by one single component (called "OfficeSharedFiles") delivered by the Access 97 Object (by the way in principle a Merge-Module - so the ALLUSERS-setting, which is already set to 1 works inherently...).

For HKCU keys to be installed automatically, advertised shortcuts have to be used. However advertised shortcuts only work with files as keypaths. The file I have to use is the Access-engine (msaccess.exe). So I have to change the component of the Access 97 object that includes the msaccess.exe file and create an advertised shortcut to msaccess.exe.

Problem #1: Because I use an "engine" (same target msaccess.exe executable with different arguments to specify, which .MDB (Access file) to start) I can now only author exactly one component with an advertised shortcut to the engine. (Windows Installer docs state that no file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component). So localization is not possible any more, even though arguments and names of the shortcuts would be different.

Is another solution for localization possible? (Without having to use approaches like wrappers from localized shortcuts that install my HKCU entries when executing them from a specific user account)

Problem #2: Simplifying matters (and renouncing the idea of localization) the next step would be to change the GUID of the component ID of "OfficeSharedFiles". So the component together with the shortcut will always be installed (, though an Access97 installation already existed on the target PC). Question: In case of multiple installations of Access97, what happens, if other Access97 installations are uninstalled. Because the same target [ProgramFilesFolder]Microsoft Office\Access 97\msaccess.exe is now registered with different components (GUIDS), theoratically msaccess.exe should be deleted but getting repaired by the current installation, when using the shortcut. Is this correct?

[Stefan Krueger]

Using auto-repair to create HKCU entries is not an ideal solution, it's a workaround, and it has limitations. The recommended solution would be to have your application create those HKCU entries when it's started by a user for the first time.

Installing the same shared file (msaccess.exe) in the same location using components with different ComponentId GUIDs is a violation of the component rules and should be avoided.

[Pizzero]

Thanks Stefan, for clarifying!

For the Access97 Object then a wrapper would be the ideal solution, which creates the HKCU entries (Yet programmed so many small helper-dll/exes, so I wanted to avoid making another one).

And BTW, in the meantime I found an answer for my question in problem #1, however only for hard-coded paths: In this case different .LNK files could be created for the same .exe target. The Access97 Module would remain unchanged and localization wouldn't be a problem any more.

But as the target file (.exe engine) for Access97 is only known at installation runtime (and saved in a property variable) I cannot use this approach.

Perhaps advertised links to localized batch files as wrappers are my (easy-to-go) solution... As the auto-repair function will create any missing HKCU entries (The original Access97 object includes these) this wrapper even would not have to implement HKCU creation!

[Stefan Krueger]

You can use a property in the shotcut target field.

[Pizzero]

No, then the shortcut cannot be advertised. It must be a file.

[Stefan Krueger]

For advertised shortscut: yes, that's true.
Sorry, I think I lost track of what you're doing.

[Pizzero]

I'm trying to create (localized) HKCU entries (for the badly programmed Access97-application) in a per-machine installation for the other users.

After lots of trials and errors, I have now found an acceptable solution for my problem without low-level programming, which I would like to share in this forum: Using advertised shortcuts to BATCH files that contain the line:

start "Program-Title" %1 %2 %3 [...]

Using the "start" command, the DOS-Box of the BATCH file and of the called program will be invisible. Thus the solution works like .LNK files that start commands silently, with this approach having the advantage that commands or paths must not exist in the file but can be dynamically created at installation run-time. (As shown, using more than 1 argument, any "Program-Title" string has to be included for the command to work properly)