I'll try to answer all three parts of this question for you
[Why is it] necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behavior
installation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATH
Linked libraries are referenced from a known set of locations. Typically these are system directories so that privileged code can use them safely (they can't be overwritten by users).
Once you understand this you realise that the set of known locations cannot not include
.. You can see the set of known locations by examining the text file
/etc/ld.so.conf. If you edit it you must run
ldconfig to update its correpsonding binary database.
The set of known locations can be extended per application by using an instance of
LD_LIBRARY_PATH, which takes a colon-separated list of directories to search. If you use this though, the kernel discards all privileges from a program - so you can't use it to cheat
sudo, for example.
how do we globally specify LD_LIBRARY_PATH, until the computer reboots [...] Is there a more elegant way than passing LD_LIBRARY_PATH as an envp argument to execle?
Setting it globally would be a really bad idea as it would break
passwd, and other privileged programs. I don't see why you can't set
LD_LIBRARY_PATH in a shell script per application, though. You don't need to start it as a "terminal program" as it doesn't write anything significant to a terminal
exec "$APP_DIR_EXE" "$@"
echo "Ooops" >&2
"$@" so that any arguments passed to the script are applied to the executable itself.
I don't know how you would start or stop a mono service so I can't help you with the specifics of that. If you update your question I'll see if there's anything I can add here.