Unable to connect to Visual Studio's Localhost Web Server.

[Flytrap Brix]

et al:

Using Visual Studio 2005 Team Edition on a Windows XP Professional
2002 SP2 computer. Other components are the aforementioned SDK.

After installing the Visual Studio SDK (February 2007) I was no longer
able to develop web projects. Most strange. There was a good deal in
the public fora pointing to Mr. Soni's blog[0], Mr. Soni's
prescription is for a different trouble than I have. He deleted a
bunch of stuff, whereas I never deleted anything, and my file
(WebDev.WebServer.exe) is indeed present in the v2 framework dir.

The first thing I checked was the SDK's readme. I see nothing in
there relating to my error, but perhaps I overlooked something since
vgrep is not the most reliable tool. I also googled the above topic
in conjunction with said SDK, but this drew up a blank. Curiouser and
curiouser. Surely I am not the only person with the SDK installed,
and surely I am not the only person with this error.

The next step I took was executing the ``Repair'' option of the .NET
2.0 installer. After rebooting the error was still present. I had no
expectation of it working, but I tried the oft-prescribed
``aspnet_regiis -i && iisreset /restart''. The error remained (as
expected).

At this point I noticed that VS was executing WebDev.WebServer2.exe
from inside the VSIDE directories. This is a different file
altogether (different name, different size, etc, etc). Odd. I tried
executing my project from the console using both the launcher in my v2
framework dir (same error), the copy from within the VS dir (same
error), and even tried using a friend's launcher (copied into a
different dir than above so I don't make things even worse!) but this
too did not work.

Presently I am uninstalling the SDK (which is a real drag because I
need it to create some build targets integrated with VS sometime
soon), but given this operation can take a considerable amount of time
even on a 1+GHz computer there is simply no way to know any time
soon. Perhaps some person more clever than myself will offer the
important solution before UNinstallation process completes?

At any rate, I hope someone can offer up the solution, and they would
have my gratitude.

</RANT>

[0] http://blogs.msdn.com/rahulso/archi...-to-visual-studio-s-localhost-web-server.aspx

 

[Flytrap Brix]

more
There has been no change after uninstalling the SDK. Since there may
be some who will no doubt ask, I will share a few more pieces of
information.
I have used netstat to verify there is indeed a program listening on
the prescribed Tcp port, but I can also verify nothing is going on
under the hood:
---------------
H:\> telnet localhost 8080
Connecting To localhost...Could not open connection to the host, on
port 8080: Connect failed
---------------
Correct behaviour, as everyone here knows, should have been standard
http traffic at that point (I'd issue my GET, the server would issue a
2xx response, followed by an RFC-compliant message [the requested
page], and then either drop the line or hang out in case I start
requesting other files, like images or anything else with a ``src''
attribute in the tag). As we can see, nothing like this is
happening.

The Windows Firewall (Internet Connection Sharing Service) is not
active, nor has it ever been active.

Before anyone gets into file ACLs, I will remind everyone those checks
are performed *after* a connection is established; at the moment I am
not connecting to anything.

I have tried both the launcher ``WebDev.WebServer.exe'' in my
framework dir, as well as my VS dir, as well as a copy from another
machine (one which works correctly), and still no joy.

I am not in any mood to re-install VS2005 Team Edition, so I am
looking for other options.

Many thanks in advance.

</RANT>

corrections to previous post: discard the word ``aforementioned'' in
first paragraph. That should have been removed after a minor
reformat.

 

[Flytrap Brix]

---------------
H:\> telnet localhost 8080
Connecting To localhost...Could not open connection to the host, on
port 8080: Connect failed
---------------

Even more (grim) It would seem my entire IIS installation is
hosed. Observe:
---------------
H:\> telnet localhost 80
Connecting To localhost...Could not open connection to the host, on
port 80: Connect failed

H:\> ftp localhost

ftp: connect :Unknown error number

---------------

It looks like I am barking up the wrong newsgroup. Sorry to bother
everyone. Good day.

</RANT>

 

[Juan T. Llibre]

re:
!> H:\> telnet localhost 8080
!> Connecting To localhost...Could not open connection to the host, on
!> port 8080: Connect failed

What that is telling you is that there's no web server on port 8080.
Should there be one ?

Try to launch the Development server from the command line...

Its parameters are :

/path:
/port:and
/vpath:

Example :

driveathto\WebDev.WebServer.EXE /pathrive:\dir\subdir /port:8001 /vpath:/test

That should bring up the Dev Server on port 8001.
This assumes that you have a file named default.aspx at Drive:\dir\subdir

 

[Flytrap Brix]

re:
!> H:\> telnet localhost 8080
!> Connecting To localhost...Could not open connection to the host, on
!> port 8080: Connect failed

What that is telling you is that there's no web server on port 8080.
Should there be one ?

Indeed there should be since that's what the /port parameter of the
WebDev.WebServer.exe does. Just run WebDev.WebServer.exe and it'll
provide usage text.

Try to launch the Development server from the command line...

This sounds familiar... it is like deja vous, all over again...
exactly like somethiing I did three (or more times) and explicitly
stated I did in previous messages...
<snip>
....

Juan T. Llibre, asp.net MVP

Thanks, Juan, but this doesn't seem to be getting us anywhere.. I say
``I ran program X'', and you respond with ``Did you try running
program X?''... it's almost as if you didn't even bother to read the
message. ::shrug:: That would be impossible though, because you're an
MVP
Thanks for the first-level try. Good luck with everything you do,
and thanks again for trying on this.

asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/
======================================

more news:

There has been no change after uninstalling the SDK. Since there may
be some who will no doubt ask, I will share a few more pieces of
information.
I have used netstat to verify there is indeed a program listening on
the prescribed Tcp port, but I can also verify nothing is going on
under the hood:
---------------
H:\> telnet localhost 8080
Connecting To localhost...Could not open connection to the host, on
port 8080: Connect failed
---------------
Correct behaviour, as everyone here knows, should have been standard
http traffic at that point (I'd issue my GET, the server would issue a
2xx response, followed by an RFC-compliant message [the requested
page], and then either drop the line or hang out in case I start
requesting other files, like images or anything else with a ``src''
attribute in the tag). As we can see, nothing like this is
happening.

The Windows Firewall (Internet Connection Sharing Service) is not
active, nor has it ever been active.

Before anyone gets into file ACLs, I will remind everyone those checks
are performed *after* a connection is established; at the moment I am
not connecting to anything.

I have tried both the launcher ``WebDev.WebServer.exe'' in my
framework dir, as well as my VS dir, as well as a copy from another
machine (one which works correctly), and still no joy.

I am not in any mood to re-install VS2005 Team Edition, so I am
looking for other options.

Many thanks in advance.

corrections to previous post: discard the word ``aforementioned'' in
first paragraph. That should have been removed after a minor
reformat.

 

[Flytrap Brix]

[ top-posting on purpose ]

Short answer: read the event log. Long answer follows...

Success! First I'll explain what was going on, and I'll point out my
mistakes.
I should mention that I should have been able to diagnose this *MUCH*
earlier, and we will visit that mistake in detail; for now let's look
at all of this.

We all know that programs just don't ``go bad'' like eggs. Programs
stop working because someone changed something (most of these wounds
are self-inflicted). I (wrongly) assumed the VSSDK was the culprit
because that was the last thing I installed. I wasn't sure if I had
installed it before or after the last web project I had to do, so I
erred on the side of ``self-inflicted wound''. This was not the only
thing which had changed. Unbeknownst to me, the IT staff changed a
setting on the Alteris server.
Alteris is a program much like MS's SMS; it remotely monitors
computers and pushes installations and configurations. So the change
made wasn't even on my computer, but it did cascade downwards. The
staff directed the Alteris program to check up on the Cisco Security
Agent program on each of the computers, and activate said service if
it is not running. The default rules they gave it prevents a host
from accepting Tcp connections. Like a shim, it slides in between the
IP device and the TCP device, so services which are ``allowed'' carry
on w/o any impact, and services which are ``denied'' never even
receive the handshake (SYN packets). So when I did a quick netstat I
could see several things listening, but none of the interesting things
were receiving accepts. What lead me to the correct diagnosis was not
the correct means at diagnosing this trouble (this is *my* second
mistake, which I'll cover in a little bit). Since the CSA operates as
an IP filter, it could ion theory block any transport we like
(brilliant idea, just bad luck on my part since the default rules are
geared for Average Joe Desktop, not Random Joe Hacker). I was able to
diagnose this by installing the simple tcp services and take a gander
at the echo/chargen/qotd demons. Sure enough, even though they were
installed and listening no connections were allowed. I then wrote a
quick program (single-user echod) and verified my program was never
receiving the connection requests. So a change on one machine (host
X) was the cause of networking troubles on another machine (machine Y)
because the very design goal of Alteris is to cascade. This is all
very cool (a good idea for anyone who has to maintain several hundred
computers), but if the wrong rules are pushed out then watch out
baby.

This is one of the few instances of which I know where changes on one
machine borked a second machine (Kerberos and LanMan changes are of
course obvious).


Mistake #1:
Since UNinstalling the SDK didn't ``fix'' my troubles I should have
instantly stopped where I was, raised my hand, and said ``I need an
adult!''. Monkeying around with the network subsystem, fooling around
with IIS, etc, threaten to make things even worse, because I could
foul up a command and introduce a SECOND problem. It's hard enough to
trouble-shoot one error at a time; I don't need to self-inflict five
more on my own head.

Mistake #2:
I should have, from the very very begining, checked the event logs and
ran a network trace, rather than rely on some twisted form of
philosophy. The event log clearly indicated the CSA was blocking
these ``bad-boys''. Installing the chargend or echod should have only
been done after checking the OBVIOUS. Right there at the very top of
the event log was a bunch of CSA stuff. A blind man could have read
it. I neglected to follow proper trouble-shooting practices on NT-
based systems and risked exacerbating my troubles. Also, if the echod
or chargend aren't working, writing my own high-level socket
application would most likely tell me even less. If I really wanted
to know what was going on I'd have to write my own IP filter (just
specify Raw for protocol when opening the socket), and this is absurd
when all this is solved by simply reading the event log first and
foremost.

I'm sure I made five or six other mistakes which ego and subconscious
prevent me from seeing, but if I had only read the event log first and
foremost I would not have made any other mistakes.

In short it is just as Wilferd Brimly says: You check your event log
and you check it often. It's the right thing to do.
Don't be a fool like me. *blush*

Now that my face is all red, I think I finally have a reason to quick
drinking bleach on Saturday nights. Eh-yup I'm pretty embarrassed.

Juan has my thanks for his response, and those who didn't respond (but
were thinking about it) have my gratitude in anonymity.

</RANT>

et al:

Using Visual Studio 2005 Team Edition on a Windows XP Professional
2002 SP2 computer. Other components are the aforementioned SDK.

After installing the Visual Studio SDK (February 2007) I was no longer
able to develop web projects. Most strange. There was a good deal in
the public fora pointing to Mr. Soni's blog[0], Mr. Soni's
prescription is for a different trouble than I have. He deleted a
bunch of stuff, whereas I never deleted anything, and my file
(WebDev.WebServer.exe) is indeed present in the v2 framework dir.

The first thing I checked was the SDK's readme. I see nothing in
there relating to my error, but perhaps I overlooked something since
vgrep is not the most reliable tool. I also googled the above topic
in conjunction with said SDK, but this drew up a blank. Curiouser and
curiouser. Surely I am not the only person with the SDK installed,
and surely I am not the only person with this error.

The next step I took was executing the ``Repair'' option of the .NET
2.0 installer. After rebooting the error was still present. I had no
expectation of it working, but I tried the oft-prescribed
``aspnet_regiis -i && iisreset /restart''. The error remained (as
expected).

At this point I noticed that VS was executing WebDev.WebServer2.exe
from inside the VSIDE directories. This is a different file
altogether (different name, different size, etc, etc). Odd. I tried
executing my project from the console using both the launcher in my v2
framework dir (same error), the copy from within the VS dir (same
error), and even tried using a friend's launcher (copied into a
different dir than above so I don't make things even worse!) but this
too did not work.

Presently I am uninstalling the SDK (which is a real drag because I
need it to create some build targets integrated with VS sometime
soon), but given this operation can take a considerable amount of time
even on a 1+GHz computer there is simply no way to know any time
soon. Perhaps some person more clever than myself will offer the
important solution before UNinstallation process completes?

At any rate, I hope someone can offer up the solution, and they would
have my gratitude.

</RANT>

[0]http://blogs.msdn.com/rahulso/archive/2006/07/11/unable-to-connect-to...