I'm currently running 2.2 (2.3 gave me some problems). Can I run 2.4 beta side-by-side with 2.2? I run the full version of Visual Studio 2005. Thanks!

juanc says:

No you can't sorry. What problems you had with 2.3?

Thanks,

mdcsoft says:

When I installed 2.3, I found that I couldn't deploy to my remote PHP box anymore.

My development is exclusively for PHP 5.1.4 on a Fedora 5 x64 system. I actually run the linux environment and my development environment (VS 2005 SP1 w/VS.PHP 2.2 on XP SP2) under two separate VMWare guests on a single 32-bit Vista host. I have experienced no problems deploying over sftp with version 2.2.

juanc says:

Could you try the latest 2.4 release?

VS.Php 2.4 download

Let me know if that solves the problem. We will back port the fixes to 2.3.

Thanks,

mdcsoft says:

Now that I've installed the beta (2.4.1.4252) - November 11 2007 01:03:40), I have noticed a few things.

  • It seems faster, though that could be because I'm running it on my Vista host instead of my XP guest under VMware.
  • Remote projects are nice, as I don't have to try to remember whether or not I deployed.
  • I still can't get remote debugging to work. I installed xdebug 2.0 RPM from a x86_64 Fedora Core 5 extras repository. Verified that it's installed and working (through phpinfo). After restarting httpd, I set some break points and tried to debug. Nothing. No break points hit.
  • Closing the IE7 browser window doesn't automatically end debugging. In fact, the browser window doesn't close. It just hangs. I have to go into the debugger and stop debugging manually.
  • It tells me that local files don't exist. For example, this line is underlined in red: require ('html.app_top.php'); It says that the file doesn't exist, even though it does. Is that a remote vs. local artifact?

It's probably a configuration issue. I feel so close to having a perfect unified development environment!
Update: I got remote debugging to work. I had to make sure I opened my firewall on both boxes. And then I modified the xdebug.ini file (in /etc/php.d) on my linux server as follows:

[XDebug]
xdebug.idekey = vsphp
xdebug.remote_enable = 1
xdebug.remote_host = 192.168.15.101
xdebug.remote_log = /tmp/xdebug/log
xdebug.remote_port = 7870
xdebug.remote_mode = req
xdebug.allowed_clients = 192.168.15.*
xdebug.remote_autostart = 1

Even that didn't work at first, so I decided to download a standalone xdebug client for Windows. (http://code.google.com/p/xdebugclient/) As soon as I ran that, Vista's firewall asked me to unblock it. Then the debugger started working! I'm very pleased.

The one thing that bothers me now is that xdebug.remote_host line. I don't like the fact that I apparently need to hard-code the debugging client's IP address, especially on a DHCP network. Is that necessary?

Thomaschaaf says:

http://xdebug.org/docs/remote

says
"xdebug.remote_host
Type: string, Default value: localhost
Selects the host where the debug client is running, you can either use a host name or an IP address."

Should work :)

Thomas

mdcsoft says:

After using it to debug for a couple of days, I'm now finding that the debug session sometimes hangs while I'm examining local variables. The only way out is to force Visual Studio to quit, which isn't fun. Even restarting apache on the server doesn't seem to help. Fortunately, I'm working on a remote project, so I'm not losing any work.

Correction: I had to kill the vsphp_dbg.exe (I think that was its name) to stop debugging. Then I kept losing my connection to the remote box (which is sitting on the floor next to me) and was forced to re-enter the user name and password.

juanc says:

Were you examining a large array in the local variables?

Also, did vsphp_dbg was pegging the CPU?

mdcsoft says:

I don't remember exactly what I was examining, but it was probably a large class or array. One of my functions actually reads a file into an array, so it was probably that. And yes, the CPU was pegged, with vsphp_dbg taking about 80% and Vmware taking the rest.