One of the things that comes with configuring software for a controlled environment is that every single thing involved has to be documented. Some people fail to realize what this means.
It means that my installation cannot contain a trivial phrase like ‘Add xyz.exe to the scheduled tasks, and have it run every night with these credentials’. Instead, I have to write something fit for ‘Deployment for dummies’, mentioning every single click, selection and user entry.
This may seem ridiculous, but otoh the purpose of these procedures is that someone without knowledge of this specific deployment can simply follow the procedure, and end up with a system that is identical to the previous / other one. And it also has the advantage that the procedure documents which files / user accounts / other resources are required for the system.
It also means that it can be a daunting task to create and test app deployment. In my case I often choose to build a script file that is part of an XCOPY deployment, and have the administrator (me) run a script.
I usually opt for the script, because it is human readable (with a definition of human = administrator) and you can read them later in case you need to check how something was done. And the major advantage of scripting things is that I don’t need human interaction -> I don’t need to write an installation manual that is as verbose and comprehensible as the Silmarillion.
One of the issues with scripts is that a script has to know where the other stuff is which it is supposed to install. Sometimes you can get away with assuming it is in the present working directory %CD%, but oftentime you can’t. And hard coding path names is not a safe option.
It took some googling, but it turns out that the environment variable %~dp0 does what I want (thank you Wes Haggard) . It expands to the physical location of the script file that is currently being executed. From that point you only need to know the location of the other files relative to the installation script, and Bjorn Stronginthearm’s your uncle.
Some of the software I develop runs on systems where it gets scheduled to execute at specific times, and I use schtasks.exe to configure those tasks in my installation script. Interesting tidbit: if you want to use schtasks to schedule a command which contains spaces, you have to enclose the command path inside the /TR argument with \” quotations so that the task scheduler doesn’t get confused. It cannot handle spaces in paths.