Dela via

Limitations on WCF Debugging

  • Artikel

This topic applies to:

Edition

Visual Basic

C#

C++

Web Developer

Express

 Topic does not apply Topic does not apply Topic does not apply Topic does not apply

Standard

 Topic applies Topic applies Topic does not apply Topic applies

Pro and Team

 Topic applies Topic applies Topic does not apply Topic applies

Table legend:

Topic applies

Applies
Topic does not apply

Does not apply
Topic applies but command hidden by default

Command or commands hidden by default.

There are three ways that you can begin debugging a WCF service:

  • You are debugging a client process that calls a service. The debugger steps into the service. The service does not have to be in the same solution as your client application.

  • You are debugging a client process that makes a request to a service. The service must be part of your solution.

  • You use Attach to Process to attach to a service that is currently running. Debugging begins inside the service.

This topic describes limitations on these scenarios.

Limitations on Stepping Into a Service

To step into a service from a client applications that you are debugging, the following conditions must be met:

  • The client must call the service by using a synchronous client object.

  • The contract operation cannot be one-way.

  • If the server is asynchronous, you cannot view the full call stack while you are executing code inside the service.

  • Debugging must be enabled with the following code in the app.config or Web.config file:

    <system.web>
  <compilation debug="true" />
<system.web>

    This code only has to be added one time. You can add this code by editing the .config file or by attaching to the service by using Attach to Process. When you use Attach to Process on a service, the debug code is automatically added to the .config file. After that, you can debug and step into the service without having to edit the .config file.

Limitations on Stepping Out of a Service

Stepping out of a service and back to the client has the same limitations described for stepping into a service. In addition, the debugger must be attached to the client. If you are debugging a client and step into a service, the debugger remains attached to the service. This is true whether you started the client by using Start Debugging or attached to the client by using Attach to Process. If you began debugging by attaching to the service, the debugger is not yet attached to the client. In that case, if you have to step out of the service and back to the client, you must first use Attach to Process to attach to the client manually.

Limitations on Automatic Attach to a Service

Automatically attaching to a service has the following limitations:

  • The service must be part of the Visual Studio solution you are debugging.

  • The service must be hosted. It may be part of a Web Site Project (File System and HTTP), Web Application Project (File System and HTTP), or WCF Service Library project. WCF Service Library projects can be either Service Libraries or Workflow Service Libraries.

  • The service must be invoked from a WCF client.

  • Debugging must be enabled with the following code in the app.config or Web.config file:

    <system.web>
  <compilation debug="true" />
</system.web>

Self-Hosting

A self-hosted service is a WCF service that does not run inside IIS, the WCF Service Host, or the ASP.NET Development Server. For information about how to debug a self-hosted service, see How to: Debug a Self-Hosted WCF Service.

See Also

Tasks

How to: Debug a Self-Hosted WCF Service

Other Resources

Debugging WCF Services