Hi Guys,
Firstly apologies for most certainly re-posting this topic, there are a number of other threads open currently talking about debugger issues and webserver.exe not functioning in an expected way. None of these have been resolved or updated for weeks at the time of writing, so unfortunately I am registering my concerns/problems with VS.Php 2010 2.9
I alike a lot of other people here have attempted running VS.Php 2010 in a number of different environments- XP (x86/x64), Vista (x86/x64), Win7 (x86/x64) using both 2010 shell and my copy of 2010 professional installed.
All windows updates are present, as are -all- current .net framework's and patches.
When attempting to debug a project, I get the error "Unable to start program C:\program files\Jcs.Software\VS.Php\2010\webserver.exe”
I can launch this application outside of visual studio; however this produces the error 'Invalid use of the VS.Php built-in web server'.
As I plan on developing for a number of platforms, most of which not based upon apache; having the ability to use the built-in web server is very advantageous and I would not have bought this upgrade / the previous product had I have known these problems were in existence.
In addition to this problem, I also cannot prevent the trial nag screen from popping up every single time visual studio is loaded or a new solution is opened. Logging in as administrator or promoting my user account to the local administrators group also results in this behaviour.
The most recent build available on your SVN results in a different webserver.exe error, which relates to a dll not being able to load.
I have gone through installing each and every build from your SVN on fresh OS installs with .net frameworks etc, all of which have resulted in experiencing the same errors.
Under windows 7 x64 i can get the debugger process to work when Project Properties > Debug > Advanced > Debug Apache is set to True.
However this *only* works under windows 7 x64 on the build available from the public download section (currently).
My apologies for hounding you guys, I understand that this is a problem which seems to have gone on for a number of builds now, I just would like to get a definitive line from yourselves to advise me about my next course of action.
If anyone else here reading this has any constructive advice or perhaps a potential fix for this issue, it would be greatly appreciated.
Many thanks in advance,
J
JDent says:
Thankfully the machine I can get this working on is my main office PC, however when i attempt to actually use the debugger, the page cannot be displayed (DNS Error). The debug page is pointing to: http://127.0.0.1:26569/index.php?XDEBUG_SESSION_START=6
I would presume that i should see httpd.exe or apache.exe running here if is had been started for debugging?
To work around this issue, do i need to install apache outside of VS.Php and then attach to it, or is there another less long-winded route which doesnt require me to manually start/stop apache whenever I need to debug a script?
Thanks muchly :)
juanc says:
Do you see any apache.exe running?
Alternatively you can always set WAMP and XDebug and use it for your debugging. WAMP is always working. The debugger would simply launch the XDebug listener (vsphp_dbg.exe)
Juan
JDent says:
Hi Juan,
Nope apache is not running after debug, hence the dns error i presume. Pardon my apparent ignorance, but should debugging with apache not just launch the version of apache which comes installed with VS.Php, as opposed to requiring me to have a separate apache installation present & running?
Do the built-in settings for Project > Properties > Debug need to be set to use the built-in web server on a fresh install? Php.ini path etc. or do you default to the built-in web server's settings when nothing is specified here? That would seem to make sense, however I cannot test this behaviour myself due to the present issues with webserver.exe
It seems odd that the product ships with a web server and will always be in the same form, yet you have to manually set the location of php.ini, port numbers, conf templates etc. on every project. If webserver.exe were to work and if one were to leave these fields blank in a project, would the built-in webservers default configuration be used? Does adding php modules into a project augment the config of the web server accordingly?
I do hope you guys manage to get the built in web server working and don't instead decide that it is too much of a pain & remove it from builds.
I would very much like to purchase further licenses of the product for the rest of my team, however we cannot use this as a competitive platform until the web server issues have been sorted. We use other web servers (IIS mainly, Zeus and others) all of which we *want* to use the same port (for simplicities sakes) which are started/stopped when debugging relevant projects. So I appreciate your suggested work around for this problem by essentially making my own debug environment and configuring it, but it’s not really that much of an option for us in the long term.
This really could be a great product if you could get this issue sorted.
Thanks for the suggestions about using another apache installation, we will have to begrudgingly use this method until you can coerce webserver.exe into behaving itself :)
Are you still working on fixing the launch issues with the web server?
Ever hopeful,
J
juanc says:
The built-in engine is supposed to handle everything with zero configuration from your part.
I'm really not sure why in some systems, Visual Studio failed to launch or attach the webserver process.
BTW, webserver.exe is just a parent process for apache.exe. Apache actually is supposed to run with a parent and child. We use the child apache process (which handles the http requests) and have webserver.exe that manages the lifetime of the child process.
The main benefit of this approach is that if apache crashes (xdebug crashes) it won't stop the debug session.
If you want to skip launching the parent webserver process, in the debug advanced settings there is an option to attach the debugger to Apache (child process)
Juan