如果你跳转到了最后的总结文件上，那么欢迎回来。
现在我们会对这个基础项目做一些改动，以便于我们可以告诉大家，如何扩展这个解决方案的，如何中断它，以及如何找出它中断的原因。
首先，我会给这个服务添加一个新的方法，以便于我们可以看到如何开始扩展这个服务。定位到“IService1”接口，然后添加下面这些代码：
[OperationContract]
float Divide(float dividend, float divisor);
现在，在这个接口上，我们拥有了一个新方法，我们必须要实现他。打开“Service1.svc.cs”，然后添加下面这些代码：
public float Divide(float dividend, float divisor)
{
if (divisor == 0F)
{
throw new DivideByZeroException();
}
return dividend / divisor;
}
现在，我们拥有了一个新方法，我们终于可以让一些事情失败了！
在Visual Studio中运行它（或者debug）,然后你会看到下面这个页面：
虽然这可以保证这个WCF服务是可以正常工作的，但是我们无法使用浏览器来调用它。取而代之，我们会求助于一个简单的，可以和WCF进行通信的Worker角色客户端。
首先，向这个解决方案中添加一个新的项目，在图中那个节点上右击：
然后，这个Worker角色需要创建一个可以和我们前面创建的WCF服务进行通信的客户端。要完成这个工作，需要在“References”上右击，然后添加一个“Service Reference”：
然后，它可以让我们选择是添加一个现有的服务，还是添加是一个解决方案中的服务。目前来说，我们使用解决方案内部的WCF服务。
try
{
for (int i = 100; i >= 0; i--)
{
Trace.WriteLine(service1.Divide(100F, (float)i));
}
}
catch (Exception ex)
{
Trace.TraceError(ex.ToString());
}
实际上，绑定到一个现有Azure实例会更加容易一些——这是因为在本地绑定你的解决方案可能会获得错误的端口号（本地的IIS端口而不是 Windows Azure Emulator运行的端口——如果你没有小心地关闭掉你的调试会话，那么这个Windows Azure Emulator端口可能会改变）。如下图所示，当查找一个本地解决方案的时候，获得了一个错误的端口号：
为了纠正这个问题，可以用你为WCF角色手工配置的端口替换掉这个端口号。你可以在“ServiceDefinition.csdef”文件中配置这个端口号，或者也可以通过在WCF角色上右击，然后打开它的属性页的方式来达到这个目的，在这个例子中，我就是这样做的：
注意，接下来你必须修改<client><endpoint>的地址属性，让它的端口号和上面配置的端口号相匹配。任何时 候，Compute Emulator都不会正确地关闭，你必须重启它们，以确保它们是匹配的，否则，你会得到一个异常，告诉你在WCF客户端配置中指定的端口没有端点 （endpoint）在监听。
为了成功地调用这个WCF服务，我们需要给Worker角色添加一些代码。我们简单地从100迭代到0，以100F作为参数调用Divide方法，最后，在迭代到0的时候，我们的代码会故意地抛出一个“DivideByZeroException”异常。
try
{
for (int i = 100; i >= 0; i--)
{
Trace.WriteLine(service1.Divide(100F, (float)i));
}
}
catch (Exception ex)
{
Trace.TraceError(ex.ToString());
}
客户端的WCF通信输出会收到一个WCF异常，但是不会包含一些细节。
snip...
10
11.11111
12.5
14.28571
16.66667
20
25
33.33333
50
100
[WaWorkerHost.exe] System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the 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 operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
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
从理论上来说，我们可以打开异常信息的细节，但是这不是一种安全的做法。为了接下来可以调试这个信息，我们需要看一看刚才配置过的Windows Azure Diagnostics。
(本文转载自51cto，译者周雪峰)