Unable to debug multiple projects in one VS instance

gusmaldonado

Hello,
I tried following the steps in this article and was unable to debug between solutions in one VS instance. Is this still possible? https://blog.devsense.com/2015/10/debugging-multiple-projects

Are there other options other than xdebug.remote_autostart? It seems this option has been deprecated in Xdebug3.

MiloslavBeno

Hello Gustavo,

There are a few minor changes. e.g. xdebug.remote_autostart is now called xdebug.start_with_request yes. I've also updated the sample project and added few more details.

Please take a look at it if it works for you now and let me know.

Thanks!

gusmaldonado

Hi Miloslav,
Thank you for the quick response. The issue that I have is that I am working with docker containers and am trying to debug between 1 web project and 5 other different services. I have 6 different containers/projects under 1 solution each with their own server url and port, e.g. host.docker.internal:8080. In your example, I see you use the built in web server option instead of custom. I have used the custom option to specify each projects server URL. I am able to start the debugger and break with the debugger in the web project, but when the application calls the service the debugger does not break even though there is a break point set. I've set the xdebug.start_with_request option to yes in the individual containers.

Am I out of luck here or is there some other work-around? I also thought perhaps I needed to pass in the session in the request, something like, "XDEBUG_SESSION_START=session_name" but that did not work. I've linked an article that discusses start_with_request in further detail regarding the session I describe above. Thanks again!
https://xdebug.org/docs/step_debug#browser_session

MiloslavBeno

Thank you for providing more details. I'm sure we will make this work.

Actually, the server URL is the URL of the service you are trying to reach from the development machine. e.g. localhost:XXXX. Anyway in this case it's likely not relevant, because you are not accessing the service from the development machine, but from the web project

There are two things we want to make sure of:
1.) Check if PHP in the container is connecting to the Visual Studio.

You can see that in the Output pane(Debug tab). If not we need to configure Xdebug in the container.

This can be done:

setup the environment variables for Xdebug in the container definition e.g. https://github.com/DEVSENSE/php-on-docker/blob/master/3%20-%20PHP%20and%20Xdebug/docker-compose.yml
OR alter php.ini and make sure there is:
- client_host=host.docker.internal
- client_port=9003

Then you should see some "action" in the output pane when the PHP in docker is requested.

2.) we have to check if path mapping is correct

Again please check Output pane for the actual path mapping that is being used.

Please let me know if that helped.

gusmaldonado

Here is the results from the output pane:

> Starting Debugger Server ...
> Debugger Server is running.
Auto-attach to process '[23748] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
Auto-attach to process '[27720] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
Auto-attach to process '[13564] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
Auto-attach to process '[31736] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
Auto-attach to process '[33076] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
Auto-attach to process '[21388] PHP.Debugger.Systray.exe' on machine 'AUSGMALDOW10L' succeeded.
> Accepting connection from Xdebug.
> Sending the socket to Visual Studio (port 64189)
> Accepting connection from Xdebug.
> Sending the socket to Visual Studio (port 64189)
Mapping dir 'C:\Apache\htdocs\Development\Platform\runtime' to 'file:///var/www/html'
Auto-attach to process '[26996] php_remote.exe' on machine 'AUSGMALDOW10L' succeeded.
Mapping dir 'C:\Apache\htdocs\Development\Platform\studio' to 'file:///var/www/html'
Auto-attach to process '[32260] php_remote.exe' on machine 'AUSGMALDOW10L' succeeded.
The program '[26996] php_remote.exe' has exited with code -1 (0xffffffff).
The program '[32260] php_remote.exe' has exited with code -1 (0xffffffff).
> Accepting connection from Xdebug.
> Sending the socket to Visual Studio (port 64189)
Auto-attach to process '[14776] php_remote.exe' on machine 'AUSGMALDOW10L' succeeded.
The program '[14776] php_remote.exe' has exited with code -1 (0xffffffff).
> Accepting connection from Xdebug.
> Sending the socket to Visual Studio (port 64189)
Auto-attach to process '[1888] php_remote.exe' on machine 'AUSGMALDOW10L' succeeded.
The program '[1888] php_remote.exe' has exited with code -1 (0xffffffff).

Above you will see 2 web projects launched "runtime" and "studio" and the 4 other are services that do not need a browser launched. I'm curious as to why I am getting the exit code on the other processes it tries to attach. That being said there are 6 processes in the list. When I execute the line with the service call I see the following message in the output pane:

The program '[32] php_remote.exe' has exited with code -1 (0xffffffff).
> Accepting connection from Xdebug.
> Sending the socket to Visual Studio (port 64189)
Auto-attach to process '[32] php_remote.exe' on machine 'AUSGMALDOW10L' succeeded.

Below is also the sample Xdebug settings within the docker file for the service I am trying to call:

# x-debug
RUN if [ "$ENABLE_DEBUG" = "true" ]; then \
        pecl install xdebug && docker-php-ext-enable xdebug; \
    fi
# append to end of php.ini the xdebug section

RUN if [ "$ENABLE_DEBUG" = "true" ]; then \
        echo "zend_extension=$(find /usr/local/lib/php/extensions/ -name xdebug.so)" > "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.log=/var/log/apache2/xdebug.log" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.remote_enable=on" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.client_host=host.docker.internal" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.mode=develop,debug" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.remote_connect_back=off" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.profiler_enable=off" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.show_local_vars=off" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.coverage_enable=false" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.client_port=9003" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
        && echo "xdebug.start_with_request=yes" >> "$PHP_INI_DIR/conf.d/xdebug.ini"; \
    fi

Sample of the docker-compose.yml settings for the service:

version: "3.9"

services:
escher:
    env_file: ./escher.env
    build:
      context: ./escher
      dockerfile: Dockerfile
      args:
        ENABLE_DEBUG: "true"
        VDI_BUILD: "false"
    volumes:
      - ./escher:/var/www/html
    ports:
      - 8090:80

volumes:
  studio:
  runtime:
  policy-manager:
  geoservice:
  escher:

MiloslavBeno

Thank you for all the details.

It seems Xdebug is configured properly and it's actually connecting back to Visual Studio, so I would say there might be an issue with directory mapping.

I can only see two mappings established:
Mapping dir 'C:\Apache\htdocs\Development\Platform\runtime' to 'file:///var/www/html'
Mapping dir 'C:\Apache\htdocs\Development\Platform\studio' to 'file:///var/www/html'

I cannot see it in the project properties on the first screenshot you've sent.
You can try to turn it off, so PHP Tools tries to map it automatically on the first request to the web service. Or it needs to be chosen manually.

Either way, you should be able to see it in the Output pane once the first request from the project is received.

To answer your question about exit code. This is possibly too much of a detail of the VS debugger implementation and it should be changed. What it actually really means is that php request has ended.

Anyway, if this will not help we might try to have an online session and take a look at it together if you'd like

Thank you,

gusmaldonado

Ok, I disabled the path mappings for the projects and it didn't seem to change anything. It may be some other issue now. I would be happy to do an online session to review and discuss. My team would be excited if I managed to get this to work properly. It would boost productivity for all developers on board. You can reach me at gus.maldonado@insurity.com so we can coordinate the session. Thanks again!

MiloslavBeno

Hi Gustavo,

Thank you very much for your cooperation and the call. I'm so happy we've been able to solve this one for you.

Just to recap the problem and solution for anyone else reading this:
There were multiple projects in the solution. Each project has its own docker container.

**Problem: ** When the Xdebug connection came, PHP Tools didn't know which project should handle the request.

**Solution: ** Specify the IDE_KEY in the phpproj file, or use the default (make sure it's saved in the project)

Now you either have to supply this IDE_KEY on the request the project as a query parameter ?XDEBUG_SESSION_START=5B2A2EE4

Or alter the dockerfile so it contains:

 && echo "xdebug.idekey=5B2A2EE4" >> "$PHP_INI_DIR/conf.d/xdebug.ini" \
 && echo "xdebug.start_with_request=yes" >> "$PHP_INI_DIR/conf.d/xdebug.ini"; \

These settings will make sure that Xdebug will provide IDE_KEY to PHP Tools and our debugger will know to which project this request belongs and what path mapping should be used.

Thanks again Gustavo, I can close this one.