I rejected VS.PHP as a viable solution for PHP debugging. It happened in 4 steps.

(1)

I was trying VS.PHP 2.8 with Visual Studio 2008, when I found that, for curl projects, it is needed to edit the file php-xdebug.ini located in the VS.PHP install folder, and then uncomment the use of the curl extension.

This means that at line that writes

;extension=php_curl.dll

it suffices to remove the ;

If a debug session is running, it must be restarted.

(2)

By default VS.PHP, in Visual Studio 2008, uses IE (Internet Explorer) as its browser. I wanted Firefox instead, so I went to the project menu and called for its properties, then I just set the “browser type” to “default browser”, which is Firefox in my case.

Again: project > “project nameproperties , as illustrated below:

20100129_vsphp_browser

(3)

The problem with Firefox was/is that it forbiddens certain exotic ports for browsing. The typical web based debugger will serve content precisely on such ports…

20100129_ffox_stop

The solution is to configure Firefox to allow access to the restricted port. For example, if it was port “19” all it takes to unblock the situation is to go to the about:config special address (type about:config at the address bar) and then create a new configuration string named

network.security.ports.banned.override

set to “19”, in this example.

20100129_ffox_configure

20100129_ffox_key

20100129_ffox_value

20100129_ffox_unlocked

(4)

But then, to my frustration, I found that VS.PHP is just no good: while trying to enter (debug / step into) a function’s code, it just let the browser in a waiting state, like if the function call wasn’t happening. What a waste of time.