现在我们会对这个基础项目做一些改动，以便于我们可以告诉大家，如何扩展这个解决方案的，如何中断它，以及如何找出它中断的原因。
首先，我会给这个服务添加一个新的方法，以便于我们可以看到如何开始扩展这个服务。定位到“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角色上右击，然后打开它的属性页的方式来达到这个目的，在这个例子中，我就是这样做的：
注意，接下来你必须修改
为了成功地调用这个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 _disibledevent=>
最新评论