Other than broader non-functional/refactor type changes, I don’t see much activity in this part of the code. The executable this produces is specific to Windows and named fdbmonitor. This is not the linux fdbmonitor, that lives in foundationdb/fdbmonitor directory.
Does any Windows user rely on it? Since it’s not maintained, I am determining if it’s safe to delete.
I personally don’t use the fdbmonitor and the Windows service. I only use the fdb_c.dllclient library, and fdbcli.exe for troubleshooting connectivity.
I don’t think anyone would be hosting a FoundationDB production cluster on Windows the “old way” any more (as a Windows Service, “net start fdbmonitor”).
For local development work, having FoundationDB installed locally is also not very practical: if you are maintaining multiple code branch that span multiple versions of FoundationDB (either older version for bug fixes, or working on support for the next fdb version), it is far easier to use multiple docker containers (that can even be running at the same time on different ports), than having to switch between multiple FoundationDB Windows service instances.
If this helps you simplify or remove code, I would say you can remove the specific win32 version of fdbmonitor.
If we still have the ability to build fdbserver.exe on Windows, one could still start a server process manually. I know of on other project on GitHub that would spawn a local fdbserver process before running a test suite, already bypassing the need for fdbmonitor.
This is my experience with the “dotnet with Aspire” workflow. Things may be different for people using a different language/platform (go, rust, node, …) on Windows workstations.
Thanks, that all makes sense. I’ll wait for a few days in case anyone else has concerns, otherwise I’ll go ahead and proceed with removing that code. Like I said, given the state of that code, I doubt anyone uses it.