Talking about WCF services implemented and debugged in Windows Azure

This article receives WCF services that have been implemented and debugged in Windows Azure (2)

Make some changes.

To facilitate your understanding of the project, we will now make some changes to the basic project to make it easier to know how to extend the solution, how to break it, and how to find out why it was interrupted.

First, in order that we can see how to start extending this service, I will add a new method on this server. Navigate to the IService1 interface and add the following code:

[OperationContract]
Float Divide (float dividend, float divisor);

Then we have a new method, so what we're going to do now is to implement it on this interface. Open Service1.svc.cs, and then add the following code:

public float Divide (float dividend, float divisor)

{

if (divisor = 0F)

{

throw new DivideByZeroException ();

}

return dividend/divisor;
}

Now, we have a new way, we can finally let some things fail!

Run it (or Debug) in Visual Studio, and you'll see the following page:

Although this will ensure that the WCF service works, we cannot invoke it using the browser. Instead, we turn to a simple, worker role client that can communicate with WCF.

First, add a new project to the solution and right-click on that node in the diagram:

The worker role then needs to create a client that can communicate with the WCF service we created earlier. To do this, you need to right-click on "References" and add a "Service Reference":

Then it allows us to choose whether to add an existing service or to add a service in a solution. For now, we use WCF services within the solution.

Try

{

for (int i = i >= 0; i--)

{

Trace.WriteLine (Service1. Divide (100F, (float) i));

}

}

catch (Exception ex)

{

Trace.traceerror (ex. ToString ());

}

In fact, it's easier to bind to an existing Azure instance--because binding your solution locally may get the wrong port number (the local IIS port instead of the port that Windows Azure Emulator runs--if you're not carefully shutting down your debugging session, Then this Windows Azure emulator port may change. As the following illustration shows, when you look up a local solution, you get an incorrect port number:

To correct this problem, replace the port number with the one you have manually configured for the WCF role. You can configure this port number in the "servicedefinition.csdef" file, or you can do so by right-clicking on the WCF role and then opening its property page, as I did in this example:

Note that you must then modify the <client><endpoint> address attribute to match its port number to the port number configured above. At any time, Compute emulator will not be properly closed, you must reboot them to make sure they are matched, otherwise you will get an exception that tells you that the port specified in the WCF client configuration has no endpoint (endpoint) listening.

To successfully invoke this WCF service, we need to add some code to the worker role. We simply invoke the divide method from 100 iterations to 0, with 100F as a parameter, and finally, when iterating to 0, our code intentionally throws a "DivideByZeroException" exception.

Try

{

for (int i = i >= 0; i--)

{

Trace.WriteLine (Service1. Divide (100F, (float) i));

}

}

catch (Exception ex)

{

Trace.traceerror (ex. ToString ());

}

The client's WCF communication output receives a WCF exception, but does not contain any details.

Snip ...

10

11.11111

12.5

14.28571

16.66667

20

25

33.33333

50

100

[WaWorkerHost.exe] System.ServiceModel.FaultException:The Server is unable to process the request due to a internal error  . For more information about the error, either turn in Includeexceptiondetailinfaults (either from ServiceBehaviorAttribute or from the <serviceDebug> revisit behavior) on the "server in order" to send the exception information Client, or turn on tracing as per the Microsoft. NET Framework 3.0 SDK documentation and inspect the server trace logs.

Server Stack Trace:

At System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood (message reply, Messagefault fault, String Action, messageversion version, Faultconverter faultconverter)

At System.ServiceModel.Channels.ServiceChannel.HandleReply (Proxyoperationruntime twist, proxyrpc& RPC)

At System.ServiceModel.Channels.ServiceChannel.Call (String action, Boolean OneWay, Proxyoperationruntime Twist, object[] ins, object[] outs, TimeSpan timeout)

At System.ServiceModel.Channels.ServiceChannel.Call (String action, Boolean OneWay, Proxyoperationruntime Twist, object[] ins, object[] outs)

At System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage Methodcall, Proxyoperationruntime twist)

At System.ServiceModel.Channels.ServiceChannelProxy.Invoke (IMessage message)

Exception rethrown at [0]:

At System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqmsg, IMessage retmsg)

At System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (messagedata& msgdata, Int32 type)

At WcfClientRole.AzureWcfBasic.IService1.Divide (single dividend, single divisor)

At WcfClientRole.AzureWcfBasic.Service1Client.Divide (single dividend, single divisor) in c:\dev\Blog\WCFBasic\ Wcfclientrole\service References\azurewcfbasic\reference.cs:line 119

At WcfClientRole.WorkerRole.Run () in C:\dev\blog\wcfbasic\wcfclientrole\workerrole.cs:line 31

Theoretically, we can open the details of the exception information, but this is not a safe approach. In order to debug this information next, we need to look at the Windows Azure Diagnostics that we just configured.

"Implementing and debugging a WCF service in Windows Azure (on)" and "Implementing and debugging a WCF service in Windows Azure (next)"

Original name: Implementing and Debugging a WCF Service in Windows Azure Author: Andy

"This article is 51CTO selected translations, reproduced please indicate the source!" 】