How to debug using a private address?

[Fred Flintstone]

I have an odd problem. I'm beating myself bloody trying to get
debugging to work. I have VS.Net 2005 installed on a Windows XP SP2
workstation and on a W2003 Server. The asp.net application is
working. I need to debug. I get the error:

"Unable to start debugging on the web server. The debugger cannot
connect to the remote computer" ...and something about it not existing
or firewall problems. I'll note here that I can manually attach to
the web server process and that the debugger is loaded on the web
server. It shows "Administrator" as connected if I manually attach.

I do have a firewall. It's a Netscreen hardware firewall with Trust,
Unstrust and DMZ zones.

Trust: 10.0.1.x
DMZ: 10.0.0.x

Trust to DMZ is configured All/All.
Trust to Untrust is configured All/All
Untrust to DMZ is set to block TCP 135.

I opened TCP 135 and UDP 4500 and 500 from untrust to DMZ. It still
doesn't work. MS says one should not try to debug through a firewall
but the workstation and server are in 2 different zones for a very
good reason and opening TCP135 to the Untrusted zone is not wise. I
assume my data path from the workstation is from trust to untrust to
DMZ.

So what do I use? I can't debug to 10.0.0.9 because all of our
websites are DNS (host header) based. How do I debug
http://myweb.mydomain.com locally? It will always resolve to a public
address. I can't say myweb.mydomain.com is 10.0.0.9 in DNS, it's a
non-routeable address.

The server's actual name is www1. I'm thinking I could debug using
this name (resolves to 10.0.0.9) but if I go to http://www1 with a
browser I get nothing.

How do I resolve this or what's the best method of debugging when the
server uses host header names and is in a DMZ?

Thanks!

[Tim_Mac]

hi Fred,
if VS is installed on the server, can you remote desktop into the server and
debug locally? apologies if this is only suggesting the obvious.

tim

[Fred Flintstone]

No, you're right! If I try to debug right on the server I get the
same error message. The remote debugger monitor window is right there
and nothing happens within it. I opened it using the "Local IIS"
option instead of entering a public URL. That should eliminate the
firewall issue I think. This is getting messy.

Here's something else wierd:

Building directory
'/test/_vti_bin/_vti_adm/aspnet_client/system_web/1_1_4322/'.
Building directory '/test/_vti_bin/_vti_adm/help/1033/publish/'.
Building directory '/test/'.

I have no idea why it's building 1.1. My app and the website are
configured for 2.0.

On Mon, 21 Aug 2006 15:12:48 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>hi Fred,
if VS is installed on the server, can you remote desktop into the server and
debug locally? apologies if this is only suggesting the obvious.

tim

[Tim_Mac]

hi Fred,
in the IIS properties for the web site, is the DEBUG verb allowed for the
file types you are trying to debug?
also, as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?

seems strange to get that error because VS 2005 is very good at debugging
compared to VS 2003 (for config issues and firewalls etc).

tim.

--------------------------
blog: http://tim.mackey.ie

"Fred Flintstone" <id**********@nospam.comwrote in message
news:ks********************************@4ax.com...

No, you're right! If I try to debug right on the server I get the
same error message. The remote debugger monitor window is right there
and nothing happens within it. I opened it using the "Local IIS"
option instead of entering a public URL. That should eliminate the
firewall issue I think. This is getting messy.

Here's something else wierd:

Building directory
'/test/_vti_bin/_vti_adm/aspnet_client/system_web/1_1_4322/'.
Building directory '/test/_vti_bin/_vti_adm/help/1033/publish/'.
Building directory '/test/'.

I have no idea why it's building 1.1. My app and the website are
configured for 2.0.

On Mon, 21 Aug 2006 15:12:48 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>>hi Fred,
if VS is installed on the server, can you remote desktop into the server
and
debug locally? apologies if this is only suggesting the obvious.

tim

[Fred Flintstone]

"in the IIS properties for the web site, is the DEBUG verb allowed for
the file types you are trying to debug?"

I'm not sure what you mean about DEBUG verbs. I don't see this or
anything relating to file types anywhere in the website configuration.

" as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?"

The web server relies on host header names and contains many domains
and subdomains on one IP address. How can I debug a subdomain on this
server locally without a proper DNS name?

Thanks for the replies! :)
On Mon, 21 Aug 2006 16:00:58 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>hi Fred,
in the IIS properties for the web site, is the DEBUG verb allowed for the
file types you are trying to debug?
also, as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?

seems strange to get that error because VS 2005 is very good at debugging
compared to VS 2003 (for config issues and firewalls etc).

tim.

--------------------------
blog: http://tim.mackey.ie

"Fred Flintstone" <id**********@nospam.comwrote in message
news:ks********************************@4ax.com.. .

>No, you're right! If I try to debug right on the server I get the
same error message. The remote debugger monitor window is right there
and nothing happens within it. I opened it using the "Local IIS"
option instead of entering a public URL. That should eliminate the
firewall issue I think. This is getting messy.

Here's something else wierd:

Building directory
'/test/_vti_bin/_vti_adm/aspnet_client/system_web/1_1_4322/'.
Building directory '/test/_vti_bin/_vti_adm/help/1033/publish/'.
Building directory '/test/'.

I have no idea why it's building 1.1. My app and the website are
configured for 2.0.

On Mon, 21 Aug 2006 15:12:48 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>>>hi Fred,
if VS is installed on the server, can you remote desktop into the server
and
debug locally? apologies if this is only suggesting the obvious.

tim

[Tim_Mac]

hi Fred,
sorry i should have said to look in the Home Directory tab on the web site
properties, and then hit the configuration button. this is where you see
the mappings for all the file types supported.
e.g. ASAX aspnet_ISAPI.dll HEAD,POST,GET,DEBUG
if DEBUG is not listed for the file types you are using, a debug request
will fail.

i use host headers too on my server. if the default web site is not being
used, you can configure it with the same home directory as your sub-domain,
this web site is set to run off localhost by default. then you could use
the default web site (off localhost) to debug.

does that make sense?
tim
"Fred Flintstone" <id**********@nospam.comwrote in message
news:gp********************************@4ax.com...

"in the IIS properties for the web site, is the DEBUG verb allowed for
the file types you are trying to debug?"

I'm not sure what you mean about DEBUG verbs. I don't see this or
anything relating to file types anywhere in the website configuration.

" as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?"

The web server relies on host header names and contains many domains
and subdomains on one IP address. How can I debug a subdomain on this
server locally without a proper DNS name?

Thanks for the replies! :)
On Mon, 21 Aug 2006 16:00:58 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>>hi Fred,
in the IIS properties for the web site, is the DEBUG verb allowed for the
file types you are trying to debug?
also, as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?

seems strange to get that error because VS 2005 is very good at debugging
compared to VS 2003 (for config issues and firewalls etc).

tim.

--------------------------
blog: http://tim.mackey.ie

"Fred Flintstone" <id**********@nospam.comwrote in message
news:ks********************************@4ax.com. ..

>>No, you're right! If I try to debug right on the server I get the
same error message. The remote debugger monitor window is right there
and nothing happens within it. I opened it using the "Local IIS"
option instead of entering a public URL. That should eliminate the
firewall issue I think. This is getting messy.

Here's something else wierd:

Building directory
'/test/_vti_bin/_vti_adm/aspnet_client/system_web/1_1_4322/'.
Building directory '/test/_vti_bin/_vti_adm/help/1033/publish/'.
Building directory '/test/'.

I have no idea why it's building 1.1. My app and the website are
configured for 2.0.

On Mon, 21 Aug 2006 15:12:48 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

hi Fred,
if VS is installed on the server, can you remote desktop into the server
and
debug locally? apologies if this is only suggesting the obvious.

tim

[Fred Flintstone]

Ok, DEBUG is listed for all asp/asp.net extentions.

So I re-assigned the default web site to the application folder. I
started debugging. First, it said the site was configured for .Net
1.1. It set it fo 2.0 for me. Then it said debugging wasn't enabled
in web.config. It did that. Then, miracle-o-miracles, it actually
loaded the site in a browser and stopped at the breakpoint I set.
That worked!

So on the server, I opened the original web I was working on by
specifying it through IIS (not by entering a URL). I get the same
error.

On my firewall, from Unstrust to DMZ, I've opened TCP port 135 and UDP
ports 4500 and 500. This made no difference.

So although I got localhost debugging to work, debugging using any
other method (remote, by URL, by IIS) doesn't work still and I can't
see it being a firewall issue. The sites in question have all their
asp.net settings set to 2.0 but the "Web Sites" branch says 1.1 and is
greyed. I don't know if this is an issue or not but I can't change it
for some reason.

Thanks!
On Mon, 21 Aug 2006 17:16:05 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>hi Fred,
sorry i should have said to look in the Home Directory tab on the web site
properties, and then hit the configuration button. this is where you see
the mappings for all the file types supported.
e.g. ASAX aspnet_ISAPI.dll HEAD,POST,GET,DEBUG
if DEBUG is not listed for the file types you are using, a debug request
will fail.

i use host headers too on my server. if the default web site is not being
used, you can configure it with the same home directory as your sub-domain,
this web site is set to run off localhost by default. then you could use
the default web site (off localhost) to debug.

does that make sense?
tim
"Fred Flintstone" <id**********@nospam.comwrote in message
news:gp********************************@4ax.com.. .

>"in the IIS properties for the web site, is the DEBUG verb allowed for
the file types you are trying to debug?"

I'm not sure what you mean about DEBUG verbs. I don't see this or
anything relating to file types anywhere in the website configuration.

" as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?"

The web server relies on host header names and contains many domains
and subdomains on one IP address. How can I debug a subdomain on this
server locally without a proper DNS name?

Thanks for the replies! :)
On Mon, 21 Aug 2006 16:00:58 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>>>hi Fred,
in the IIS properties for the web site, is the DEBUG verb allowed for the
file types you are trying to debug?
also, as an alternative testing option, could you run the web site off
127.0.0.1 and try debugging via localhost?

seems strange to get that error because VS 2005 is very good at debugging
compared to VS 2003 (for config issues and firewalls etc).

tim.

--------------------------
blog: http://tim.mackey.ie

"Fred Flintstone" <id**********@nospam.comwrote in message
news:ks********************************@4ax.com ...
No, you're right! If I try to debug right on the server I get the
same error message. The remote debugger monitor window is right there
and nothing happens within it. I opened it using the "Local IIS"
option instead of entering a public URL. That should eliminate the
firewall issue I think. This is getting messy.

Here's something else wierd:

Building directory
'/test/_vti_bin/_vti_adm/aspnet_client/system_web/1_1_4322/'.
Building directory '/test/_vti_bin/_vti_adm/help/1033/publish/'.
Building directory '/test/'.

I have no idea why it's building 1.1. My app and the website are
configured for 2.0.

On Mon, 21 Aug 2006 15:12:48 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>hi Fred,
>if VS is installed on the server, can you remote desktop into the server
>and
>debug locally? apologies if this is only suggesting the obvious.
>
>tim
>

[Tim_Mac]

well i'm glad you got it working at least on the localhost.
i'm no expert on remote debugging so i can't really comment on why it isn't
working as expected. perhaps someone more knowledgable would be able to
comment now that some more clues are uncovered?

tim

[Fred Flintstone]

Thanks Tim, you help was immensely useful.
On Mon, 21 Aug 2006 18:57:55 +0100, "Tim_Mac"
<ti********@community.nospamwrote:

>well i'm glad you got it working at least on the localhost.
i'm no expert on remote debugging so i can't really comment on why it isn't
working as expected. perhaps someone more knowledgable would be able to
comment now that some more clues are uncovered?

tim