Hi folks,
Now this is a really seriously smart question!
Well, I have been going through all the MSDN Help documentation to resolve
this, and I'm still unable to get the debugging working on my local machine
for the ASP.NET application that is on the webserver.
Here is the quick rundown,
I have attached the html help file on this topic, to demonstrate what steps
I actually have taken to resolve this, and no joy.
Only one thing I must mention is that in the section where it says:
To configure IIS after running setup on Windows Server 2003
1
2
3<<<<< here where I don't find Security option on the right click on the
machine name...
But then the .NET was installed after IIS anyway..so what am I missing
guys???
Thanks alot in advance guys..
Visual Studio
Error: Unable to Start Debugging on the Web Server
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_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/unable2debug.html#vxtbshttpservererrorsthingstocheck)
* _Web Applications on Remote Servers_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/unable2debug.html#vxtbshttpservererrors
webapplicationsonremoteservers)
* _Web Applications Stored in Visual SourceSafe and Using FrontPage
Server Extensions_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/unable2debug.html#vxtbshttpservererrorswebapplicationsstoredinvisual
sourcesafeandusingfrontpageserverextensions)
* _Manually Attaching_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/unable2debug.html#vxtbshttpservererrorsmanuallyattachin
g)
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_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/unable2debug.html#vxtbshttpservererrorsmanuallyat
taching) and _ASP.NET Debugging: System Requirements_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/vxgrfaspnetdebuggingsystemreq
uirements.htm) .)
* 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_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/vxtskdebugmodeinaspnetapplications.htm)
.
* Does the Web.config file 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.
* You need to be a member of the Debugger Users group or an
administrator if the ASP.NET worker process runs under your own user account.
* You need to be a member of the Administrators group if the ASP.NET
worker process runs under any other user account besides your own.
* 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 enter as one line at the
command line:
<DVD Drive>:\wcu\dotNetFramework\dotnetfx.exe /t:c:\temp
/c:"msiexec.exe /fvecms c:\temp\netfx.msi"
âorâ
Insert the Visual Studio .NET Requirements disc and enter as one line at the
command line:
<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 set up properly? To verify this, check
the Default Web Site settings.
To check IIS security settings for the Default Web Site
1. From the Start menu, choose Programs, then Administrative Tools, and
click Internet Services Manager (Windows 2000) or Internet Information
Services (Windows XP).
2. 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.
3. Right-click Default Web Site and choose Properties.
4. In the Default Web Site Properties window, select the Directory
Security tab and click Edit.
5. In the Authentication Methods dialog box, select Anonymous Access
and Integrated Windows Authentication (if not already selected).
6. Click OK to close the Internet Services Manager or Internet
Information Services dialog box.
7. 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
1. From the Start menu, choose Programs, then Administrative Tools, and
click Internet Services Manager (Windows 2000) or Internet Information
Services (Windows XP).
2. 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.
3. Right-click the Web application and choose Properties.
4. In the Web application Properties window, select the Directory tab.
5. Under Application Settings, click Create.
The application name appears in the box.
6. Click OK to close the Properties dialog box.
7. 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 or ATL Server
and remote debugger components on the server?
* Do you have the necessary access privileges to debug processes
running under the system account? You need to be a member of the Debugger
Users
group or an administrator if the ASP.NET worker process runs under your own
user
account. You need to be a member of the Administrators group if the ASP.NET
worker process runs under any other user account besides your own. (See
_Adding Debugger Users and Configuring DCOM_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/vxtskinstallingdcom.htm)
for procedural
information.)
ASP.NET applications run as ASPNET by default. To debug an application
running under aspnet_wp.exe, you need Administrator privileges or edit the
machine.config file for aspnet_wp.exe so that aspnet_wp.exe runs under your
user
account. (On Windows Server 2003, the worker process is called w3wp.exe rather
than aspnet_wp.exe, and you can change the account it runs under using IIS.)
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 must be an 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.
IIS on Windows Server 2003
When you install Visual Studio .NET on Windows Server 2003, ASP.NET is not
enabled by default. To develop Web projects, you must run the Security
Lockdown Wizard after completing Visual Studio .NET Setup.
If you run the Security Lockdown Wizard before Visual Studio .NET setup is
complete, the correct version of ASP.NET may not be enabled. Visual Studio
.NET Setup installs a new version of ASP.NET. To ensure that the latest
version
of ASP.NET is enabled, you must run the Security Lockdown Wizard after setup
has finished.
To configure IIS after running setup on Windows Server 2003
1. From the Start menu, choose All Programs.
2. Choose Administrative Tools and then choose Internet Information
Services.
3. Right-click your machine name in the left pane and choose Security.
4. On the first screen of the IIS Security Lockdown Wizard, click Next.
5. Verify that HTTP is set to Automatic and click Next.
6. In the Request Handlers list, check ASP.NET and each instance of
n:\WINDOWS\Microsoft.NET\Framework\<version number>\aspnet_isapi.dll.
7. Click Next.
8. Click Finish to complete the wizard
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.)
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
1. Start the application without debugging. (From the Debug menu,
choose Start Without Debugging.)
2. 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 (w3wp_wp.exe for ASP.NET applications under Windows Server 2003).
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
1. Use Visual Studio .NET or another text editor to open the
machine.config file for the application.
2. Find this process model attribute:
enable
If enable is set to TRUE, the application runs under aspnet_wp.exe or
w3wp.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
1. In Solution Explorer, right-click the project name and choose
Properties from the shortcut menu.
2. In the <Project> Property Pages dialog box, open the Web Deployment
folder and choose General.
3. 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).
4. Click OK to close the <Project> Property Pages dialog box.
See Also
_Debugging Script and Web: Errors and Troubleshooting_
(file:///C:/Documents%20and%20Settings/sam.al-kauraishi/My%20Documents/vxgrfscriptweberrors.htm)
____________________________________
_Send feedback on this topic to Microsoft_
(javascript:sendfeedback('_653926', '[EMAIL PROTECTED]'))
 Microsoft
[Non-text portions of this message have been removed]
ASP Resources www.asp-dev.com
============================================================
Learn over lunch. Get the developerWorks newsletter and
enjoy tools, code, and tutorials, along with your sandwich.
XML, Linux, Web services, Java -- and peanut butter!
http://www.topica.com/partner/AP-1RMZ49/partners/ibm/aff_landing.html
============================================================
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/asp/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
