Cxbx-reloaded: Task: Child Debugger Documentation

[RadWolfie]

@ergo720 and @x1nixmzeng

Is there a reason for build/win32/Cxbx.ChildProcessDbgSettings file in .gitignore file?

In my opinion, it should be include for every developer using this project. Since it is easy to attach child process quickly without manually look up for correct Cxbx's process to attach.

Plus the extension for it is optional.

Since Child Debugger extension doesn't enable or read standalone file. Let's make a simple documentation to enable it either on Wiki section or README file. Once this is done, we can close it.

[LukeUsher]

I think it's to prevent Visual Studio interfering/conflicting with Cxbx-Reloaded's included debugger

[ghost]

You can save the VS debugger settings in a SUO file (user option file) or in this standalone XML ChildProcessDbgSettings file, there is no difference between the two options afaik. I once made the mistake to select the XML and so VS created the file and then git wanted to push it in my commits. I didn't want it and so added the entry in gitignore.

[ghost]

To add more detail: the entry in gitignore is not there to prevent conflicts, it's only used by git to avoid uploading to the repo that user file if present, but it will still exist and work as expected on the local pc of the user

[RadWolfie]

You can save the VS debugger settings in a SUO file (user option file)

Real question is... will it still be in there if another developer doesn't have it installed? Plus .vs folder, where .SUO file is in, doesn't show in the repo. XML Standalone file would be best way to preserve it.

@LukeUsher Then Cxbx's debugger should pop up a warning message of child process is already attached? Since one debugger can be attach at a time. Another debugger can call one of the function to see if a debugger is in used. With this way, developer will know need to either de-attach or run without debugger.

EDIT: Sorry, I got confused when you talked about XML.

[ghost]

The SUO file is automatically created by VS when the solution is saved, so it's not a problem if it is not included in the repo. The debugger settings are just added to that file if using it and that requires having the child debugger installed. I don't have anything against using the XML file though, so if you want it we can go that way.
https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-user-options-dot-suo-file

[RadWolfie]

that requires having the child debugger installed.

How is this require child debugger installed? If it's not installed, then Visual Studio doesn't read this file. If a child debugger extension is installed, then it should automatic attach to child process after start with debugging without hiccups since Cxbx.ChildProcessDbgSettings file exist.

Currently, @PatrickvL and I agree this is needed. @LukeUsher do you agree we should have child debugger file include in the repo?

If @LukeUsher agree, then by default Cxbx.ChildProcessDbgSettings should be in the repo.

EDIT: @ergo720 if you also agree as well, then let's go this way.

[RadWolfie]

@ergo720 Standalone file, .ChildProcessDbgSettings, in our repo isn't considered as user settings. It should be a project settings. After all, any data from extension will be remove from visual studio's saving process if extension isn't installed.

After attempt to save the file base on repo's config file for child debugger on launch, it doesn't appear to be enabled by default. I'm not sure if this is intended or not. I guess we'll have to manually enable it every time we need to pull clean dump from the repo. Since the extension is acting as per user than per project when it should had support per project by checking the file existence.

Instead of adding the file, perhaps somewhere we need to document instruction to enable child debugger after installation.

[RadWolfie]

Since child debugger isn't attaching to second process on my end. I had investigate and found Cxbx is using ShellExecute instead of CreateProcess to create second process. If ShellExecute isn't the problem for you guys. Then it will be a different issue.

EDIT: I also tested it with SUO and standalone, didn't work for me at all. Since @ergo720 said it works for him, it must be third-party protection causing it not to work.

[ghost]

On my end it's attaching fine so I don't think it's the ShellExecute function the problem. The only issue I have is that sometimes the debugger is turned off for some unknown reason. I'm using the SUO file at the moment for saving the settings.

[x1nixmzeng]

I had accidentally added the file to git whilst working on the cxbx-debugger.

However since the extension settings are designed to be per-user (and not project-specific) there is no reason to keep the preference file under source control.

[RadWolfie]

Yeah, it's too bad standalone file isn't supported for per-project. 🤷‍♂️

[PatrickvL]

I've experienced the same as @ergo720 a few times already : a sudden loss of "child process debugging", only noticable after a few runs without hitting breakpoints that should've got triggered.

If someone ever discovers why that happens, please document it!

[x1nixmzeng]

If we agree on a section, I can add some documentation for developing/debugging cxbx-debugger.

My workflow involves debugging the child process 'CxbxDebugger.exe' and explicitly not 'Cxbx.exe' which gets a bit confusing.

[RadWolfie]

It would be best to have a page "Child Debugger" then split into two different sections in it. One for Visual Studio extension of Child Process Debugging and other for Cxbx Debugger. Top section could have a introduction between two different options. Does this make sense to you? If you're not sure, you can put "TODO" in any sections.

[x1nixmzeng]

I've added an entry to the wiki here: https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/wiki/Child-Process-Debugging

Feedback/changes/screenshots welcome

[RadWolfie]

LGTM! 😉

[PatrickvL]

Nice work on the documentation @x1nixmzeng !

Now, before close this issue, let's discuss one final thing: do we or don't we put the settings file under version control?

I see one benefit : the configuration would already be done correctly for new developers.
I see no downsides?

[RadWolfie]

Here's few major cons:

• Before, I recommended standalone file to be put in version control. Now, I don't recommend at all since standalone file is not selected by default after extension installer.
• Another reason is the extension is a per-user basis.
• And it will override standalone file after change from SUO to standalone file, including the other way around. For different developer's reason. (see below)
• Does not work for every developer's computer. It's a hit and miss thing which both of you said. It's always a miss breakpoint every time for myself.

There is a few cons with only one pro for it.

If you're thinking about provide XML file format, then that's the only thing we can do.

[ghost]

A detailed documentation of the child debugger has been written to the wiki section by @x1nixmzeng so I'm closing this.