1

I want to append the installation folder of my program as value to the path variable of user and system variables.

I followed michaelmoo's instruction. https://stackoverflow.com/a/21390793/9678802

The problem is that the existing value of path variable will be removed.

Bighted19
  • 119
  • 7
  • Did you wipe out your Path trying this? [There are some tricks you can use to try to restore your Path variable](https://superuser.com/q/523688/11906). Not options to toy with, but last resorts. – Stein Åsmul Sep 21 '18 at 00:45
  • @SteinÅsmul No, I had a backup. I am using the free version of Advanced Installer now. – Bighted19 Sep 22 '18 at 20:29
  • OK, but you can verify that the path was indeed wiped out? I am asking because certain OS registry keys are under protection and / or auto-recovery. I do not think this is the case for the Path (yet). – Stein Åsmul Sep 22 '18 at 20:52
  • Using [TARGETDIR]appname.exe as path value replaced the path value and using [~][TARGETDIR]appname.exe as path value replaced path in registry with a REG_MULTI_SZ file and [TARGETDIR]appname.exe as value. – Bighted19 Sep 22 '18 at 20:58
  • Obviously please make sure that package never gets used - compulsive warning :-). I wish system restore would preserve the Path specifically, so it could be easily restored in several generations. Advanced Installer is a very nice product. – Stein Åsmul Sep 22 '18 at 21:47

1 Answers1

1

Digression: Adding to the Path involves some security risks, some performance issues, and can cause application interference - and probably a few other things. It is best avoided in general. It is a "known risk" avoided by deployment professionals - if they can help it.

The concept of AppPaths is a (partial) alternative to updating the Path environment variable. It allows your application to be started from the Start => Run dialog, but it does not work from the command line.

Seems to not work from command prompts.

Warning: Ouch, that answer is very bad indeed (with apologies to the author who clearly tried to help others). That procedure should not be followed in any shape or form though! It is so dangerous that I have seen people sent out the door for far less. Wiping out a whole developer teams' environment path with a package deployment will cause drama - that you can be sure of. The warning really needs to be that strong in this case. I have seen it happen, and even by packages made by experienced professionals.

Built-In Support: As far as I am concerned, the correct answer from the above "thread" is this one. Windows Installer has built-in support for adding environment variable that takes care of all merging and update issues - and it even has rollback support - meaning your environment variable will be restored to its original state should the package installation fail. This built-in feature is a "must use" functionality.

Deployment Tool: So the built-in feature has to be used, but how when the tool does not support it? The best option is to get a "real deployment tool", especially since there are several further problems with the Visual Studio Installer Projects (Note: this is not pitching products, it is telling people about serious pitfalls that will cause real problems in almost all cases - what product you choose is up to you - obviously - but the VS Installer Project just isn't a complete solution).

WiX: Updating the Path variable using WiX is simple enough. And the documentation for the Environment element.

Orca: Though it is possible to "post-process" your compiled MSI and create the required entry in the Environment table, I would recommend that you use a proper tool instead that has been tested and designed to help you succeed in general. A comma wrong or a star wrong in the Environment table and you get completely wrong behavior.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164