中-在Windows-Azure中实现和调试一个WCF服务 (在中文版windows中,用区位)

教程大全 2025-07-20 00:09:07 浏览次

在Windows Azure中实现和调试一个WCF服务（中）

原创2011-03-15 16:07:33为了把在Windows Azure中运行的，使用强大的WCF框架的服务暴露出来，Windows Azure提供了一个WCF角色。无论在哪个框架和平台上构建复杂的，具有高度可扩展性的系统，通过它们的功能进行逻辑分组，针对那些分组来抽象代码，并且分别执行它们，都是一种简单而高效的扩展性策略。

本文接《在Windows Azure中实现和调试一个WCF服务（上）》和《在Windows Azure中实现和调试一个WCF服务（下）》

做一些改动

如果你跳转到了***的总结文件上，那么欢迎回来。

现在我们会对这个基础项目做一些改动，以便于我们可以告诉大家，如何扩展这个解决方案的，如何中断它，以及如何找出它中断的原因。

首先，我会给这个服务添加一个新的方法，以便于我们可以看到如何开始扩展这个服务。定位到“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服务。

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角色上右击，然后打开它的属性页的方式来达到这个目的，在这个例子中，我就是这样做的：

注意，接下来你必须修改的地址属性，让它的端口号和上面配置的端口号相匹配。任何时候，Compute Emulator都不会正确地关闭，你必须重启它们，以确保它们是匹配的，否则，你会得到一个异常，告诉你在WCF客户端配置中指定的端口没有端点（endpoint）在监听。

为了成功地调用这个WCF服务，我们需要给Worker角色添加一些代码。我们简单地从100迭代到0，以100F作为参数调用Divide方法，***，在迭代到0的时候，我们的代码会故意地抛出一个“DivideByZeroException”异常。

for (int i = 100; i >= 0; i–)

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

catch (Exception ex)

Trace.TraceError(ex.ToString());

客户端的WCF通信输出会收到一个WCF异常，但是不会包含一些细节。

[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 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。

本文接《在Windows Azure中实现和调试一个WCF服务（上）》和《在Windows Azure中实现和调试一个WCF服务（下）》

原文名：Implementing and Debugging a WCF Service in Windows Azure作者：Andy

【编辑推荐】

.NET 的 WCF 和 WebService 有什么区别？

微软论坛的斑竹回答如下：严格来说是行业标准，不是技术，使用XML扩展标记语言来表示数据（这个是夸语言和平台的关键）。微软的Web服务实现称为 Web Service.它使用Soap简单对象访问协议来实现分布式环境里应用程序之间的数据交互。 WSDL来实现服务接口相关的描述。此外Web services 可以注册到UDDI中心.供其客户查找使用。后来微软做了 Web Service的安全，性能，数据加密、解密，托管宿主等多方面的扩展，称为WSE系列，这个是过度产品，最高到WSE3.0.后来就是WCF时代。：其实一定程度上就是 Web Service,因为它支持Web Service的行业标准和核心协议，因此 Web Service和WSE能做的事情，它几乎都能胜任，跨平台和语言更不是问题（数据也支持XML格式化，而且提供了自己的格式化器）。但是WCF作为微软主推一个通讯组件或者平台，它的目标不仅仅是在支持和集成Web Service,因为它还兼容和具备了微软早期很多技术的特性。根据微软官方的解释，WCF（之前的版本名为“Indigo”）是使用托管代码建立和运行面向服务（Service Oriented）应用程序的统一框架。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案，且能与已有系统兼容协作。 WCF是微软分布式应用程序开发的集大成者，它整合了平台下所有的和分布式系统有关的技术，如Enterprise Sevices(COM+) Remoting、Web Service(ASMX)、WSE3.0和MSMQ消息队列。以通信(Communiation)范围而论，它可以跨进程、跨机器、跨子网、企业网乃至于 Internet；以宿主程序而论，可以以，EXE，WPF，Windows Forms，NT Service，COM+作为宿主(Host)。 WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全模式则包括SAML， Kerberos，X509，用户/密码，自定义等多种标准与模式。也就是说，在WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术要素都包含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。

WCF,WebService,Remoting,Socket的通讯区别到底是什么？

使用socket无疑是效率最高的。但是，在复杂的接口环境下，socket的开发效率也是最低的。故在兼顾开发效率的情况下，可以使用remoting来代替socket开发。并且：1、Tcp通道的Remoting速度非常快。你可以通过端口查看工具，发现remoting比直接socket传输的内容，应该是属于同一个数量级的。我的另一个担心是，大客户端数量的情况下，remoting传输效率会不会很低，结果经过现场测试，同时对300个客户端进行数据通信，不存在信息丢失情况。 2、虽然是远程的，但是非常接近于本地调用对象。也就是完全符合面向对象思想。 3、可以做到保持对象的状态直接使用socket传输机制，我们必须花大量的精力来处理异常、断网、死机等现象，使用remoting，这些工作会大大简化。 2：remoting vs webservice1、webservice在framework2.0状态下只能寄宿于IIS等应用服务器中。微软直到3.0才提供了servicehost来寄宿webservice，这就极大地限制了webservice在使用中的灵活性。在framework2.0环境下，如果你有一个应用要脱离IIS而存在，就不得不抛弃webservice。（除非你想代码实现一个WEB应用服务器）2、remoting可寄宿在你自己的代码中，也可寄宿在windows服务及IIS中。最大程度的提供了开发和部署的灵活性。 3、remoting在使用http通道的时候，也如webservice一样支持穿透路由。 4、remoting与websercie相比，提供双向通信。哪怕是将remoting寄宿在IIS中，也支持。 5、webservice客户端自动生成的代理类比较复杂。而remoting一般来说，都是手动编写客户端代码。 6、当然，webservice最主要优势是，它是一个行业标准，而remoting只是微软自己内部的标准，如果你的应用要脱离微软的平台，就只能使用webservice了。 3：remoting vs wcf与wcf的比较，更多的是从平台的普及度上来说。在当前环境下，2.0的普及度还是最高的。