0

I have made an installer, a Visual Studio SetupProject, which installs a software I developed and checks if a certain program is installed on the target machine. If not, it launches its original installation file. This file is copied to the target machine during the installation and is launched throughout a CUSTOM ACTION.

Everything goes well with the installation but I have only one problem:

The separate installer, which I didn't develop, should append a PATH to the User Environment Variables referring to the path of a BIN folder in its own installation folder. It doesn't! I checked the PATH registry value of the User Environment Variables and it really doesn't get updated.

However when I install the program separately everything goes well!

I tried to to change the PackageAs Property of the attached installation file from vsdpaDefault to vsdpaLoose in order to make the operation, probably, a bit more "separate" sort of say but it didn't change anything.

Why do the Environment Variables not get updated? My guess is that my installer doesn't have some kind of rights necessary to change these variables.

BTW I'm using Visual Studio 2010.

  • "why does a third party program not do what I expect it to do" is probably best taken up with customer support. – Deleted User Jun 13 '14 at 09:23
  • @Bushmills It does what it should when normally installed. Just when my installer calls its installation, it doesn't! – RegisteredFreak Jun 13 '14 at 09:26
  • Starting a program from the installer is a very bad practice. It runs with UAC elevation, inherited from setup.exe. And is a fail-whale in your case, high odds that it inherits the environment variables from setup.exe and won't use the ones in the registry. Verify your assumptions about it not writing the registry keys by using SysInternals' Process Monitor. – Hans Passant Jun 13 '14 at 14:21
  • @HansPassant Please take a look down to the comment. – RegisteredFreak Jun 20 '14 at 06:51

1 Answers1

0

I believe Hans has the answer. If you fire off that setup from yours as a custom action then it runs with the local system account. That means it is not running as the current interactive user therefore it cannot update the current user's path because it's not running as the current user.

This setup by definition cannot be an MSI-based install because it would fail - you can't do recursive MSI installs - therefore it is code based and depends on running in the interactive user's context.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Thanks @PhilDW and @ Hans Passant. Your argument makes sense. Now the question is how to make the external installer run as the current user, or better said, how make the installer run automatically from my installer and still have the rights to change values in the HKCU?? Hans says that the whole thing is a bad idea. I don't really follow here. – RegisteredFreak Jun 20 '14 at 06:50