اخوانى انا واقع فى مأزق مع asp.net

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

بسم الله الرحمن الرحيم

H:dotNetFrameworkdotnetfx.exe /t:c:temp /c:msiexec.exe /fvecms c:tempnetfx.msi

Error: Unable to Start Debugging on the Web ServerSee 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

:wcudotNetFrameworkdotnetfx.exe /t:c:temp /c:"msiexec.exe /fvecms c:tempnetfx.msi"

—or—

Insert the Visual Studio .NET Windows Component Update disc and run

:dotNetFramework dotnetfx.exe /t:c:temp /c:"msiexec.exe /fvecms c:tempnetfx.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 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 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 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 Property Pages dialog box.

بسم الله الرحمن الرحيم