- I suggest installing PHP7 through the IIS Web Platform Installer so it does the Handler Mapping vs having to mess with that manually (i.e. assigning PHP extension to php-cgi.exe) – but there’s a lot of guides out there for doing that yourself if you want.
- That’ll probably leave you with a slightly older version so then just go install latest PHP7 bits over the top – we want the non-thread-safe (NTS) builds when running under IIS FastCGI (supposedly the most performant approach)
- Ideally you don’t mind springing for PHP Tools for Visual Studio… this package provides comforts like Intellisense and PHP project templates… and I also noticed that PHP Tools automatically configures XDebug debugging bits for us which is nice vs figuring that out manually (at least the first time)… turns out its just some php.ini settings (see below).
- so basically you just launch site in Visual Studio debug (F5) and PHP Tools will ask you if you want it to configure debugging for you… the brief wrinkle here is that it then went off and installed/configured PHP5.x… hence the main reason I’m posting this – to affirm we can then indeed just go copy the pertinent settings from the PHP5.ini to our PHP7.ini…
- if you go look at the php5.ini that PHP Tools set up you’ll see the following settings added at the bottom (for me it went under: C:\Program Files (x86)\iis express\PHP\v5.6):
zend_extension=”C:\Program Files (x86)\IIS Express\PHP\v5.6\ext\php_xdebug.dll”
xdebug.remote_enable = on
xdebug.remote_handler = dbgp
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000
xdebug.remote_mode = req
- so then we need to go get xdebug for php7 (again, the non-thread-safe version, i believe) and drop that DLL it in your PHP7\ext folder (mine was here: C:\Program Files\PHP\v7.0\ext)
- and lastly just copy/paste those same settings into php7.ini and tweak the xdebug path
Now you can go set breakpoints and step debug.
Check out your web project properties page and you can see how PHP5 vs PHP7 is chosen as the runtime, easy peasey!
Last note: I had some screwy behavior where certain files wouldn’t take breakpoints but would still step thru if I broke in a different file earlier in the call stack… I think this went away after restarting VS and/or making sure i had a clean rebuild.