更改PATH后必须重新启动

Question

It could be that this is no strictly speaking a WIX issue, but it should be a well known problem related to setup with well established best practices. I just can't find these practices on Google. Using WiX 3.6, Windows 7, Visual Studio 2008, but the installation must support Windows from XP to newer.

I'm installing a COM object that depends on some third party DLLs. The object itself is registered okay, and all the DLLs are installed in installation folder, and setup adds this folder to system's PATH environment variable. The code looks like this:

<Component Id="RequiredLibraries" Guid="$(var.RequiredLibrariesGUID)">
    <?include redist.wxi?>
    <Environment Id="PATH" Name="PATH" Value="[INSTALLDIR]" Permanent="no" Part="last" Action="set" System="yes" />
</Component>

On my machine I can use the object immediately after installation, but on some machines I must reboot the computer. This reboot is a pain, and I don't know why is it necessary, nor why only on some machines. I can <ScheduleReboot After="InstallFinalize"/> , but I'm hoping for some better solution. So, feel free to answer any of these questions:

1. What is the best common practice for this issue? I can't pack everything to a single DLL, so I need a solution for several DLLs.

2. What I could I do to enable the use of the COM object (by making the change to PATH visible to the rest of the system), without resorting to reboot, or user relogin, or Explorer restart? Does Windows Installer broadcasts WM_SETTINGCHANGE message? Should I broadcast it in custom action?

3. How could I detect and ask the user to reboot/relogin only if it is required, and not always? (reboot is not required on some machines)

4. How can I schedule something less painful than reboot that works just as well?

Answer 1

There are two scenarios I know of:

1) Application doesn't honor WM_SETTINGCHANGE broadcasts ( typically anything hosted by service control manager )

2) A behavior in MSI when it chooses not to send the broadcast. Per WriteEnvironmentStrings Action :

(emphasis added)

Environment variables do not change for the installation in progress when the WriteEnvironmentStrings action or RemoveEnvironmentStrings action are run. On Windows 2000, Windows Server 2003, Windows XP, and Windows Vista this information is stored in the registry and a WM_SETTINGCHANGE message is sent to notify the system of the changes when the installation completes. Another process can receive notification of the changes by handling these messages. No message is sent if a restart of the system is pending. A package can use the MsiSystemRebootPending property to check whether a system restart is pending.

I've worked around #2 by writing a .NET custom action (using Environment class) that makes a meaningless change just to get the broadcast to occur after MSI has done it's thing.