VS.NET Debugging ASP.NET using Host Header Names
Richard Murray
I'm trying to set-up a number of websites in IIS using a
single IP address and host header names, which I have
working OK.
My problem is that I can't get Visual Studio.NET's
debugging to work properly. I'm not sure whether I need
FrontPage server extensions installed or whether certain
permissions need setting.
Has anyone tried this and maybe got some pointers for me?
Thanks,
Richard
Chris Crowe [MVP]
Have you added the sites (DNS NAME) to the TRUSTED sites tab of IE on the PC
with VS.NET?
Here is the default help file on the topic:
Chris
Error: Unable to Start Debugging on the Web Server
See Also
Debugging Script and Web: Errors and Troubleshooting
When you try to debug on an application running on a Web server, you may
sometimes get a message with this error message:
Unable to start debugging on the web server
If you encounter these errors, there are several things to consider:
Things to Check
Web Applications on Remote Servers
Web Applications Stored in Visual SourceSafe and Using FrontPage Server
Extensions
Manually Attaching
Things to Check
If you get an "Unable to start debugging on the Web server" error, try
checking the following things:
Are you running a version of Windows that allows the Visual Studio debugger
to automatically attach to a Web application? If not, you need to launch the
application without debugging and manually attach to it. (For more
information, see Manually Attaching and ASP.NET Debugging: System
Requirements.)
Does your Web application have a Web.config file?
Does the Web.config file enable debug mode) by setting the debug attribute
to true? For more information, see Debug Mode in ASP.NET Applications.
Does the Web.config contain any syntax errors? You can check for syntax
errors by running the Web application without debugging. (From the Debug
menu, choose Start Without Debugging.) If there are syntax errors in
Web.config, detailed information will be displayed.
Are you a member of the Debugger Users group? If you are logged in as
Administrator, is Administrator in the group?
Did you create the project by specifying a specific IP address
(100.20.300.400, for example)? Debugging a web server requires NTLM
authentication. By default, IP addresses are assumed to be part of the
Internet, and NTLM authentication is not done over the Internet. To correct
this problem:
When creating the project, specify the name of the machine on your Intranet.
-or-
Add the IP address (http://100.20.300.400) to the list of trusted sites on
your computer. (From the Internet Explorer Tools menu, choose Internet
Options, and then select the Security tab).
Does the machine running IIS server have Visual Studio .NET Remote
Components installed?
Was IIS installed on the local machine (the machine running Visual Studio
.NET) after Visual Studio .NET was installed? IIS should be installed before
Visual Studio .NET. If it was installed afterwards, you may need to repair
the .NET Framework.
To repair the .NET Framework
Insert the Visual Studio .NET disc and run
<DVD Drive>:\wcu\dotNetFramework\dotnetfx.exe /t:c:\temp /c:"msiexec.exe
/fvecms c:\temp\netfx.msi"
-or-
Insert the Visual Studio .NET Windows Component Update disc and run
<CD Drive>:\dotNetFramework\ dotnetfx.exe /t:c:\temp /c:"msiexec.exe /fvecms
c:\temp\netfx.msi"
Is the URL for the project start page properly specified? Are the extension
and project directory correct?
Are the IIS security settings setup properly? To verify this, check the
Default Web Site settings.
To check IIS security settings for the Default Web Site
From the Start menu, choose Programs, then Administrative Tools, and click
Internet Services Manager (Windows 2000) or Internet Information Services
(Windows XP).
In the Internet Services Manager or Internet Information Services dialog
box, click the tree control for your machine. In the Web Sites folder, find
Default Web Site.
Right-click Default Web Site and choose Properties.
In the Default Web Site Properties window, select the Directory Security tab
and click Edit.
In the Authentication Methods dialog box, select Anonymous Access and
Integrated Windows Authentication (if not already selected).
Click OK to close the Internet Services Manager or Internet Information
Services dialog box.
Click OK.
For an ATL Server application, verify that the DEBUG verb is associated with
your ISAPI extension.
For an ASP.NET application, make sure the virtual folder for the application
has an Application Name set in Internet Services Manager or Internet
Information Services.
To designate the virtual folder for the Web application
From the Start menu, choose Programs, then Administrative Tools, and click
Internet Services Manager (Windows 2000) or Internet Information Services
(Windows XP).
In the Internet Services Manager or Internet Information Services dialog
box, click the tree control for your machine. In the Web Sites folder, find
the Web application.
Right-click Default Web Site and choose Properties.
In the Default Web Site Properties window, select the Directory tab.
Under Application Settings, click Create.
The application name appears in the box.
Click OK to close the Properties dialog box.
Click OK to close the Internet Services Manager or Internet Information
Services dialog box.
Web Applications on Remote Servers
If the Web application is on a remote server, check the following:
Were the proper setup programs run to install ASP.NET/ATL Server and remote
debugger components on the server?
Are you a member of the Debugger Users group on the Server? Do you have the
necessary access privileges to debug processes running under the system
account?
ASP.NET applications run under inetinfo.exe (the IIS process) or the ASP
worker process aspnet_wp.exe, depending on security settings. The
aspnet_wp.exe process runs as SYSTEM by default. To debug an application
running under aspnet_wp.exe, you need to have Administrator privileges or
edit the machine.config file for aspnet_wp.exe so that aspnet_wp.exe runs
under a user account. To debug an application running under inetinfo.exe,
you need to be Administrator on the machine running inetinfo.exe.
ATL Server applications run under inetinfo.exe or the ATL worker process
dllhost.exe, depending on security settings. To debug an application running
under inetinfo.exe, you be Administrator on the machine running
inetinfo.exe, or you can configure dllhost to run as a particular user using
the Common Language Runtime application settings
Are you using Terminal Server to try to debug a Web application on a remote
machine? Remote debugging of native Web applications using Terminal Server
is supported under Windows XP. It is not supported under Windows 2000 or
Windows NT.
Web Applications Stored in Visual SourceSafe and Using FrontPage Server
Extensions
If the Web application is stored in Visual SourceSafe and uses FrontPage
Server extensions as its Web Access mode, check the following:
Is Visual SourceSafe located on the same machine as the FrontPage Server/Web
server? If so, you can debug using Integrated Authentication. (To check the
Integrated Authentication setting, see the procedure To check IIS security
settings for the Default Web Site earlier.)
Another way to solve this problem is to change the Web Access Mode from
FrontPage to File Share.
To change the Web Access mode to File Share
In Solution Explorer, right-click the project name and choose Properties
from the shortcut menu.
In the <Project> Property Pages dialog box, open the Common Properties
folder and choose Web Settings.
Under Web Server Connection, click Web Access Mode and choose File Share
from the list box.
Click OK to close the <Project> Property Pages dialog box.
Manually Attaching
If you follow the troubleshooting steps and still get an error message when
you start debugging, you may want to try debugging your application by
manually attaching.
To manually attach
Start the application without debugging. (From the Debug menu, choose Start
Without Debugging.)
Attach to the appropriate IIS process or worker process. By default,
inetinfo.exe for ATL Server applications or aspnet_wp.exe for ASP.NET
applications. Use the following procedures to determine which process an
ASP.NET or ATL Server application runs under.
To check which process an ASP.NET application runs under
Use Visual Studio .NET or another text editor to open the machine.config
file for the application.
Find this process model attribute:
enable
If enable is set to TRUE, the application runs under aspnet_wp.exe. (This is
also the default setting.)
If enable is set to FALSE, the application runs under inetinfo.exe.
To check which process an ATL Server application runs under
In Solution Explorer, right-click the project name and choose Properties
from the shortcut menu.
In the <Project> Property Pages dialog box, open the Web Deployment folder
and choose General.
Look at the Application Protection setting.
If the setting is Low (IIS Process), the application runs under
inetinfo.exe.
If the setting is Medium (Pooled), the application runs under a dllhost.exe
process (in common with other pooled ATL Server applications).
In the setting is High (Isolated), the application runs under a dllhost.exe
process (separate from other ATL Server applications).
Click OK to close the <Project> Property Pages dialog box.
See Also
Debugging Script and Web: Errors and Troubleshooting
--
Chris Crowe [IIS MVP]
Looking for IIS information, tutorials, and ADSI code samples try
www.iisfaq.com
the unofficial IIS support web site, you may like what we have to offer you
today...
"Richard Murray" <ric...@rpmzone.demon.co.uk> wrote in message
news:886e01c20595$5af978c0$3bef2ecf@TKMSFTNGXA10...