Looking for Server.PSI and Server.{portnum}.psi file copied to \Windows\System32 when running in a Windows Service

[georgeinva2004]

I've noticed with the latest 4.0.0 branch that when running in a Windows service, that the library is looking for Server.PSI in \Windows\System32 and when the Server.{portnum}.psi is created, it too is in System32. Further, I noticed that the log files are now appearing in System32. This seems like a behavior change. Not sure if that's a .Net 8 change or a library change. In any case, do we want that behavior, or should we force the PSI search and log file locations to be the running assembly location (or make it a configurable item)?

Thoughts?

[marcus-j-davies]

Hi @georgeinva2004

The only notable change in v4 is

File.Copy("server.psi",ProcessName, true);
...
...
PSI.FileName = ProcessName; /* ProcessStartInfo */

This is so it starts up (and terminates) a process for each instance of the library - previously it was not possible to have more then 1 instance (Multi ZWave Network)

Other then that, nothing else has changed with file loads
Doesn't a windows service have a working directory of System32 by default - hasn't that always been the case?

Could it be .NET is writing (by default) into the current working directory?

we could use maybe:

string AppPath = System.IO.Path.GetDirectoryName(System.AppDomain.CurrentDomain.BaseDirectory);
string SourceExec = Path.join(AppPath,"server.psi")
string DestinationExec = Path.join(AppPath, ProcessName)
File.Copy(SourceExec DestinationExec, true);

I will need to also alter the zombie paths (so it terminates any instance that is being restarted)

foreach(Process Zombie in Zombies)
{
   Zombie.Kill();
   Zombie.WaitForExit();
   File.Delete(DestinationExec);
}

Note: Nothing above is tested

[georgeinva2004]

I think I understand what changed. I was inadvertently using V3 with the test harness I use to check out new builds of ZWaveJS.NET when I thought I was actually running V4 (version control issue). When I moved to V4 with the PSI download method disabled, I discovered the "change" in behavior. You are correct, Windows Services use System32 as the default directory. However, I do like the idea of having either control of the PSI file location or defaulting to the location of the app.

[marcus-j-davies]

@georgeinva2004

I want to merge some changes I have done for the PSI build scripts.
I will create a PR for them, and include the ability to override the directory that is used for PSI location.

im thinking something like.

// Driver.cs
public static string PSIDirectoryOverride

IF this is set, the lib will use the directory as provided by this property, else will behave as is?

and yes, I removed the ability to download the PSI - maintaining the automated builds become cumbersome, but building the PSI is relatively easy 😅

[georgeinva2004]

Awesome! Thank-you!