LP on .NET

July 29, 2011

Debugging WCF Services in IIS

Filed under: C#,WCF — Larry Parker @ 3:43 pm

Until recently I’ve always self-hosted my WCF services in console apps during the development cycle, and in Windows services for production deployments.  Debugging my WCF services has always been very easy, especially when hosting in a console app.  I would simply run my console app solution from Visual Studio in debugging mode (by pressing F5), set a breakpoint in the WCF service code, have my client app hit the service, and the breakpoint would be hit in the debugger.

For my current project, I’m hosting WCF inside of IIS and could not easily debug my WCF services.  Even if I started up my web site from Visual Studio with F5 and set a breakpoint, it would not get hit when my client called the service.

As a crude workaround, I inserted the following line of code in my WCF service code:

System.Diagnostics.Debugger.Break();

 

Now when my client called the service I would get the following dialog box:

image

This approach allowed me to debug my WCF service code, but it was annoying since I had to modify my source code to insert the Debugger.Break() code, and then respond to a dialog box.

The solution to all of this is to simply run your web site and then attach Visual Studio to the aspnet_wp.exe process (mentioned in the above dialog box).  To do this, bring up Visual Studio’s Debug menu, select “Attach to Process…”, and then double click on aspnet_wp.exe in the list of available processes.

Now when your client hits your WCF service, your breakpoint will be hit in Visual Studio and you can debug your service code as expected, without having to insert Debugger.Break().

Hope this helps!

Advertisements

WCF Test Client

Filed under: C#,WCF — Larry Parker @ 3:14 pm

An invaluable tool I’ve been using quite a bit lately is the Windows Communication Foundation (WCF) Test Client.  You can find out more about it here on MSDN, but it’s basically a tool that acts as a service client by consuming an existing service and letting you interact with it through a nice user interface.

The program is named WcfTestClient.exe and can be found on your development machine in the following locations, depending on which version of Visual Studio you have installed:

Visual Studio 2008 C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE
Visual Studio 2010 C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Here’s a screenshot of the WCF Test Client working with a service that performs temperature conversion:

image

Notice how the tool dynamically creates types based on the service’s WSDL, lets you enter values for the request message properties, and displays the response message properties after you call the service (by clicking the Invoke button).

The XML tab at the bottom of the screen can also be used to inspect the exact request and response SOAP messages:

image

This is especially useful for debugging your service calls (e.g. to ensure the expected message namespace is being used).

Hope this helps.

June 21, 2011

Errors Generating WSDL for WCF Service

Filed under: .NET,C#,Software Development,WCF — Larry Parker @ 2:42 pm

Our team recently started specifying a namespace for our WCF data contracts.  We were already supplying a namespace for our service contracts, but for some reason we never did it for the data contracts.

The service contracts look something like this:

[ServiceContract(Namespace = ServiceConstants.ServiceContractNamespace)]
public interface ICustomerService
{
    [OperationContract]
    CustomerResponse GetCustomer(CustomerRequest request);
...
}

The namespace is defined as a constant in a static class:

public static class ServiceConstants
{
    public const String ServiceContractNamespace = "http://Company/2011/06/Product";
...
} 

So we just applied the same technique to our data contracts:
[DataContract(Namespace = ServiceConstants.ServiceContractNamespace)]
public class CustomerResponse
{
    [DataMember]
    public String LastName;

    [DataMember]
    public String FirstName;
}

But when we tried to generate a service proxy we got the following error (once we set IncludeExceptionDetailInFaults to true):

System.Xml.Schema.XmlSchemaException: The global element ‘http://Company/2011/06/Product:CustomerResponse’ has already been declared.

After much trial and error, we renamed the class to CustomerResp and everything worked fine.  We originally thought there must have been an older assembly causing the trouble, but a Google search turned up this page…  Problem solved!  🙂

Evidently, WCF uses some reserved suffixes (like Response and Request) and this causes problems when the data contract has the same namespace as the service contract.

Fortunately, the workaround was as simple as changing the data contract’s namespace:

[DataContract(Namespace = ServiceConstants.DataContractNamespace)]
public class CustomerResponse
{
...
}

public static class ServiceConstants
{
    public const String ServiceContractNamespace = "http://Company/2011/06/Product";

    public const String DataContractNamespace = "http://Company/2011/06/Product/Data";
...
}

Aside from fixing the problem, it seems like a good idea to separate the namespaces between the service and data contracts.

But this was a tough one (took all morning).

Hope this helps.

June 9, 2011

WCF Tracing can also be used on the Client

Filed under: .NET,C#,Software Development,WCF — Larry Parker @ 4:42 pm

I helped track down an issue at a customer today where we couldn’t determine if one of the client machines was making any WCF service calls to the server.

So we used the WCF Configuration Editor Tool (SvcConfigEditor.exe) and the WCF Service Trace Viewer Tool (SvcTraceViewer.exe) on the server to check for incoming messages.

This helped us get to the bottom of the problem, but it would have been better if we could have directly done a trace on the client machine to monitor the outgoing messages.

I had used Fiddler for something like this many years ago, but before I threw that into the mix I figured I would check if the WCF tools could be used on the client side.

And they can!  🙂

You simply need to run SvcConfigEditor.exe on the client application’s app.config file and set it up for message logging and / or tracing.  Now after you restart your client app you can run SvcTraceViewer.exe and see the WCF service calls being made from it.

Hope this helps!

June 30, 2009

Now that’s a Property Name!

Filed under: .NET,C#,Humor,Visual Studio,WCF — Larry Parker @ 4:07 pm

Wow, I just came across a property in .NET that is over 100 characters long!  Check this out:

private void Application_Startup(object sender, StartupEventArgs e)
{
    var x = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

In fact, it looks like System.ServiceModel.MessageSecurityVersion has all kinds of lovely property names:

untitled

Good thing for IntelliSense!  🙂

Create a free website or blog at WordPress.com.