Will services use per app paths key to find dependencies?
In an effort to reduce the need for reboots, I'm attempting to use the per-application path entries for all my .exe's. Some of these are services.
Error 1053 occurs when starting these services now since I have moved the path locations from the PATH env var to their respective per-app paths in the registry.
Is this expected to work and if so, are there additional things that need to be done? Or will services simply ignore the per-app path references?
I don't know the answer from memory; is there any chance that you're the author of the services? If so, do you happen to know how the dependent DLL is being loaded? Does running Dependency Walker on the installed service executable tell you anything?
I myself am not the author but the developers are on site. I'm not sure if they use LoadLibrary or LoadLibraryEx, or some other method to do this work.
Yes, dependency walker does successfully find the dependencies.
I'm beginning to think that App Paths registry won't suffice for system services. At least thats what my tests are showing.
An unscientific test here seems to corroborate what you're seeing (an own-process service installed into LocalSystem with interact-with-desktop, using both LoadLibrary and "normal" implicit linking); strange, because the service can successfully read its own App Paths data using RegQueryValueEx, but the fact remains.
Probably... I know the SCM doesn't respect WM_INISETTINGCHANGE broadcasts ( env var changes ) and I suspect that it doesn't respect AppPaths either.
But I have been known to work around this. Consider writing some code inside the service to query the AppPaths registry key and then apply it to the Process Environment space. This is the equivilant of saying
SET PATH=%PATH%;MORESTUFF
Then if you are doing LoadLibrary calls it should work without needing a reboot to get the SCM off it's ass to check for an AppPath/EnvVar change.
