Make_it_easy-CSDN博客

原创 Essential Windows Communication Foundation

后四章的全部内容请参考http://www.cnblogs.com/danielWise 个人博客。谢谢。

2010-11-24 14:59:00 793 1

翻译第四章绑定本机.NET应用程序间的通信

进程间，跨进程，通信就是在同一台机器上的两个独立进程间的通信。进程内，或者在进程中，通信就是在一个进程内两个软件模块的通信。这些通信类型一起组成了我们所称的本机通信。 应用程序域是通过进一步对一个Windows进程拆分并将多个.NET应用程序在安全性和活动范围层次进行隔离的.NET中的架构。这意味着应用程序域是另一个可以被.NET程序跨越的边界。因为这些我们定义了两个额外的名词: 应用程序域间和内部应用程序域。 应用程序域间或者跨应用程序域。在

2010-11-10 17:21:00 1131 1

转载使用SingleTagSectionHandler实现简单配置节

当我们程序中使用配置文件时，Asp.net中使用是Web.config，WinForm和Console中使用是App.config。通常用的最多是AppSettings节,有的时候觉得不够用，另一选择就是自己实现SectionHandler，来实现自定义配置节。看下面的示例AppSettings节:对于上面两个配置项，要写个自定义配置类是不是很麻烦，我们还有另一种简单实现方法，使用 SingleTagSectionHandlerMSDN是这么描述的：Handles configuration se

2010-11-09 16:36:00 731

翻译第四章绑定跨机器通信

这一部分描述了用来在.NET应用程序间跨机器通信的绑定。我们将描述如何通过配置文件和代码来自定义每一个绑定。每一个绑定都会在一个典型场景的上下文中查看。提示以”net” 为前缀的绑定应该被用于.NET应用程序之间WCF把所有在.NET应用程序之间使用的绑定加上”net”前缀。绑定名字的前缀是一个暗示，让我们知道应该选择一个特定的绑定来使用。这意味着这些绑定有特殊的仅能用于.NET应用程序的特性。相反的，所有以”ws”为前缀的绑定意味着使用Web Services的非.NET应用程序。netTcpBindin

2010-11-05 17:28:00 648

翻译第四章绑定选择一个合适的绑定

WCF中有9个预设绑定。这些绑定中的每一个都满足一个特殊分布式计算的需求。很多因素决定了为一个特殊应用选择哪一个绑定，包括安全，互通性，可信赖，性能和事务需求。表4.2 通过显示9种预设绑定支持的公共特性来进行比较。这张表可以用来为一个特定需求选择最好的绑定。最常见的用来选择一个绑定的方法是检查你的应用程序需要的特性并由此确定一个满足那些需求的绑定。表4.2 比较了每一个预设绑定的特性以便于你可以基于自己的需求选择绑定。有很多特性，包括互操作，间隔，可信赖和事务。比如，如果你的应用程序需要在一个不可信赖的网

2010-11-04 14:02:00 517

翻译第四章绑定

正如第三章“信道”所描述的，信道栈是一个由一个或多个信道组成用来处理消息的层次通信栈。绑定是预先设置的信道栈。它们代表了在客户端和服务端之间的线上契约。每个绑定由通信中涉及的传输，编码和协议确定。WCF使用绑定为多样化通信场景集合配置信息。最普通的通信场景，比如网络服务，REST/POX 服务和基于队列的应用都在盒子外面提供。例如，basicHttpBinding绑定意味着使用基于ASP.NET Web Services的服务或者与WS-I 基础协议1.1 相适应的服务。ws2007HttpBi

2010-10-30 15:54:00 482

翻译第三章信道总结

信道栈是由一个或者多个信道组成用来处理消息的分层通信栈。信道可以是协议信道或者传输信道。传输信道位于信道栈的最底层用来在一个传输协议(比如，HTTP,TCP,MSMQ)上传输消息。协议信道(又名层次信道)通转发和修改消息来实现协议(安全，可信赖消息，事务，等等)。 信道工厂和信道监听器组成了发送消息和接收消息的基础。它们用来创建信道栈并把信道栈暴露给应用程序。 WCF在把信道模型细节从开发人员中抽象出来的过程中做了很好的工作。大多数开发人员将会使用继承自ClientBase<

2010-10-29 11:26:00 562

翻译第三章信道 ICommunicationObject

ICommunicationObject 接口(查看列表3.8)是WCF中所有通信对象(信道，信道工厂，信道监听器，等等)的基础。打算创建自定义信道或者直接使用信道的开发人员需要了解这个接口。WCF中的通信对象需要实现一个特殊的状态机。状态机表示了所有通信对象的状态变化。这种情况就像其他通信对象(比如，套接字)所处理的那样。ICommunicationObject接口(还有与它相关联的方法，状态和事件)的目的是为了实现状态机。这允许WCF能够将按同样的方式处理通信对象，并让他们下层实现与抽象层分

2010-10-29 11:16:00 673

翻译第三章信道-操作契约和信道形状

信道通过信道形状来完成它们所支持的多种类型消息交换模式。比如，一个基于TCp的传输信道将会实现IInputChannel和IOutputChannel,因为这些通道都是固有单向的。其他的传输信道基于其他协议比如TCP可能需要实现多个信道形状。开发人员不直接与信道形状打交道。对应的，WCF选择一个服务的基于OperationContract的信道形状。表3.1列出了多个你可以在OperationContract上设置的影响信道形状结果的属性。注意大多数信道形状有一个无状态的(默认)和会话感知变量。

2010-10-28 17:31:00 1402 1

翻译第三章信道形状

信道形状WCF支持不同的消息交换模式:单向，双工和请求-回复。为了实现每种方式，WCF提供了10种不同的称作信道形状的接口。其中五个形状称作IOutputChannel, IInputChannel, IDuplexChannel, IRequestChannel和IReplyChannel.每个形状都有一个等效的支持会话的形状。它们包括IOutputSessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionCha

2010-10-27 18:45:00 657

翻译第三章信道

信道就是WCF应用程序接收和发送所有信息的通道。它负责在一个持续的方式中准备并传输消息。信道是为传输，协议和消息交换定义的。信道被放到一起来创建信道栈。信道栈是处理消息的分层通信栈。比如，一个信道栈可以由一个TCP传输信道和一个事务协议信道组成。这样的一个信道栈允许使用在网络中的客户端和服务端之间使用TCP协议和事务流转来发送/接收消息。 信道栈的目标是把一条消息转成与发送方，接收方兼容的线上格式并传输这条消息。有两种类型的信道用来做这个: 传输信道和协议信道。传输信道总是位于信道栈的

2010-10-26 19:06:00 545

翻译第二章契约总结

总结 这一章覆盖了非常多的契约背景，它们是互通性的基础。契约精确地描述了一个服务所能理解的消息。 WCF高度利用SOAP于契约定义中。特别的，它使用WSDL来描述服务终结点，使用XSD来描述数据。定义在WSDL中的服务操作用来在运行时把收到的请求转发给正确的.NET类。类似的，通过XSD契约定义的XML文件在运行时被反序列化成.NET类型而且发送给服务操作。合二为一，WSDL和XSD定义提供了对服务实现中的.NET类型一种基于标准的实现。 三种类型的契约的

2010-10-22 11:58:00 524

翻译第二章消息契约

消息契约 消息契约描述了发送给一个服务以及从一个服务接收的SOAP消息的结构，并且允许你检测和控制SOAP消息头和消息体中大部分细节。而且数据契约能够让使用XML元数据定义(XSD)标准的系统之间互通，消息契约能够让任何通过SOAP通信的系统互通。 使用消息契约能够通过直接访问SOAP消息头和消息体提供对发送给一个服务以及从一个服务接收的SOAP消息的完全控制。这允许使用简单或复杂的类型来定义SOAP部分的精确内容。就好比当你需要对数据序列化的完全控制时你可以从DataCon

2010-10-22 10:10:00 657

翻译第二章数据契约等效

数据契约等效 如果你在使用WCF暴露服务而且使用svcutil.exe来为创建访问服务代码，一般情况下你不需要关心在客户端和服务端间传输的消息的线上表示。数据契约知道WCF把一个.NET类型序列化成一个XML信息集和讲一个XML信息集反序列化成一个.NET类型。XML信息集可能在线上以文件或者二进制形式编码，这些取决于通信过程中所使用的绑定，但是再次，.NET代码不会意识到编码的存在。这种方式就好比你在代码中使用.NET类型但是一个基于标准的XML信息集的编码表示在线上具体传输。<br

2010-10-21 18:08:00 462

翻译第二章数据契约版本

数据契约版本 变化是不可避免的。企业改变，技术改变，法律改变，软件契约也会改变。在面对软件的变更时，一个坚实的版本控制是必须的。我们必须为不可避免的变化做好提前准备同时对已经存在的客户端进行向后兼容处理。 对数据契约版本控制来说，最常见的需求是想已有的数据契约中添加成员。通过这一部分描述的不间断的描述，你可以自由的做任何改动而不会破坏现有客户端。但是如果你需要打破现有客户端的向后兼容性，你必须通过改变数据契约的名字或者命名空间来定义另一个版本的数据契约。 一

2010-10-20 17:05:00 624 1

转载给程序员的一些非常不错的资料

一、Intel 给开发人员推荐的资料列表（2010年下半年） Intel Recommended Books for Developers 其中包含了硬件：硬件，电源，存储，无线软件：多线程和多核技术，高性能计算，图形游戏，用户关注嵌入式：设计，软件，操作系统，安全，优化。IT部门：策略和决策，服务器和数据中心，客户端 二、jQuery Fundamentals jQuery Fundamentals 这可能是我见过写得

2010-10-19 14:57:00 476

翻译第二章定义类的层次结构

定义类的层次结构 复杂类型一般在代码中以类的形式实现。复杂类更进一步通过增加特殊结构的继承关系来定义。这种方式，一个通用类型比如”price” 可以派生出为一个更加特殊的类型如”stock price” 或者“house price”.WCF支持通过在WSDL中合适的表示的类的继承关系，在类结构和XML之间序列化和反序列化它们同时从每个类中取出属性并加入到一个集合中。 在列表2.17中，类Price由三个元素和一个子类组成。StockPrice,继承自Price.命名空间

2010-10-19 11:59:00 989

翻译第二章数据契约

在一个服务内部，功能性的应用由代码实现的。在服务外部，功能性服务在WSDL中定义。在一个WCF服务中，应用程序数据在简单和复杂类型表示；而在服务外部，应用程序数据由XML元数据定义表示。WCF数据契约提供了对代码定义的.NET CLR类型与W3C组织定义用来在服务外部通信的XML元数据定义之间的映射。 使用WCF，开发人员花费更多的时间在代码和接口语义上，在XSD和WSDL语法上花费的时间会更少。那不是说XSD和WSDL语法不重要;它们是跨平台系统上进行互操作必要前提。但是编译器也显示

2010-10-18 19:53:00 595

翻译 WSDL中的操作名字，类型，操作和命名空间

WCF 根据服务端源代码中定义的内部类名称和属性来生成外部暴露服务实现。这些实现通过服务中的MEX终结点暴露出来并在设计阶段时被客户端以WSDL形式使用。接下来在客户端，WSDL会被用来写一些代码来建立可以与服务端通信的适当的消息格式。所以你选择的类，方法和参数的名字与服务范围潜在相差很远。 然而，在服务的接口暴露内部名字和外部细节是很不好的形式。比如，你可能有一个叫BurgerMaster的分配算法，你想在外部以Resources名字暴露这个算法。或者可能有内部的编码标准要求你

2010-10-12 20:51:00 3772

翻译第二章(契约在一个服务中实现多个契约和终结点)

一个服务作为一系列终结点被定义的。每个终结点都有一个地址，绑定和契约。契约就是暴露终结点能力的。地址就是这些应用或服务从网络的哪个地址可找到，契约是关于如何访问他们的。 在终结点和契约间有一对多的关系。一个终结点可以只有一个契约，但是一个契约可以被很多终结点引用。尽管一个终结点可以仅仅确认一个契约，接口聚合使能一个单独的契约来暴露多个接口。另外，多个有同样绑定但是不同契约的终结点可以位于同一个地址，给一个单独终结点实现所有契约的假象。 通过在一个服务中的多个终结点

2010-10-07 11:07:00 890

翻译第二章(契约实现一个双向契约的客户端部分)

为了参与到一个双工消息交换模式中，客户端必须实现WCF的ABCs-必须在客户端定义服务要把消息发送到的地址，指导服务端如何把消息发送给客户端的绑定，定义消息内容和格式的契约。幸运的是，当你生成一个客户端代理而且在运行时使用信道结构时，WCF很大程度上考虑到了这些。 生成一个客户端代理类，你可以使用svcutil.exe或者添加服务引用。代理定义一个与服务同名的接口，并在后面加上Callback.如果服务契约接口是IStockService,客户端接口就是IStockService

2010-10-07 10:12:00 534

翻译第二章(契约实现一个双向服务契约的server 部分)

一个双向契约包含服务终结点和客户端终结点的接口实现。在契约类型中，服务端契约在客户端实现。列表2.6为一个提供stock price更新的服务定义一个服务契约。它使用双工通信以便于一个客户端可以注册更新，服务将周期性的发送更新消息给客户端。客户端通过调用服务端的RegisterForUpdates操作来初始化通信。服务然后会创建一个线程来周期性的通过调用客户端的PriceUpdate操作来发送更新消息。LISTING 2.6 双工服务契约:服务端实现为了完整性，相关配置文件在列表2.7中显示。注

2010-09-28 21:41:00 468

翻译第二章两个单向契约VS一个双工契约

两个单向契约VS一个双工契约 你可以通过两个不同消息交换模式来解决双向通信问题。你可以使用两个单向契约，或者你可以使用一个双工契约。对于两个单向契约来说，客户端和服务端都是独立的WCF宿主。它们分别暴露终结点来可以让另一个向自己发消息。因为它们是全面的服务，它们可以暴露多个终结点，使用多个绑定和独立的定义契约的版本。使用一个双工契约，客户端不用明确的变成一个WCF服务而且不用很复杂(很灵活)来选择绑定或者暴露其他终结点。更进一步，定义客户端终结点的地址，绑定和契约是由信道工厂在双

2010-09-27 13:10:00 588

翻译第二章(契约双向操作)

请求-回复通信是客户端与服务端最普遍的消息交换模式。通信在客户端被初始化，客户端发送一个请求消息给服务端，然后服务端发送一个返回消息给客户端。如果返回消息很快，那么通信过程可以是同步的，所以客户端应用程序阻塞等待反馈。如果请求和回复之间会有延时，请求-回复模式可以在客户端使用标准.NET技术实现异步调用。在那种情况下，WCF会在发送请求给服务端后立即把控制返回给客户端应用程序。当服务接收到反馈以后，一个.NET回调方法被调用来完成WCF回复。然而，如果服务端需要初始化消息，比如一个通知或者提示？如果客

2010-09-26 22:09:00 554

翻译第二章单步操作

当一个客户端需要向一个服务端发送消息但是不接受返回消息时，但不消息交换模式很有用。使用这个模式，客户端只需要消息成功传递的确认；它不需要服务端返回一个精确的消息。有时单步模式被错误的称作"发后不理"。在实际应用中，它是"发送和理解"因为调用者接收到一个消息成功提交到通信信道的确认。 WCF支持在服务操作层次的单向消息交换模式。服务操作可以被标记为单向而且基础结构将会使那种情况更完善。当一个客户端调用服务端的一个单项方法时，或者更准确的说，当一个客户端发送一条消息给一个操作被标记为单向的服务终结点时，控制

2010-09-26 17:47:00 762

翻译第二章(契约异步请求回复操作)

异步请求回复操作 好的设计会降低用户必须等待一个任务结束然后初始化另一个任务之前的情况。例如，当一个e-mail客户端正在下载新邮件，你仍然可以读或者删除已经下载下来的邮件。或者当一个浏览器正在下载一个网页上引用的图片时，你仍然可以拖动网页或者跳转到任何地方。在客户端程序中的多任务形式是通过异步设计模式来完成的。 在WCF中，请求-回复服务操作导致当服务操作在执行时客户端被阻塞。更深一层，由svcutil.exe生成的代理代码使用阻塞来调用服务通信信道栈。这使得客户端应

2010-09-24 21:28:00 515

翻译第二章(契约续同步请求回复操作)

同步请求回复对服务操作来说，同步请求回复消息交换是最普通的模式。这个模式就像任何人在面向过程或者面向对象语言中编程的那样。请求回复模式是本地过程调用的原型，对远程过程调用也很普通。图片2.3显示了一个请求回复交互，一个在客户端运行的代理发送请求给一个服务，服务端同步返回消息给客户端。 WCF使得在客户端和服务端进行请求-回复通信非常容易。在设计阶段，你使用添加服务引用或者svcutil.exe来调用服务元数据终结点而且生成一个客户端代理来模仿服务操作的签名。这允许客户端代码像本地函数调用一样调用代理上的

2010-09-24 10:56:00 534

翻译第二章(契约续服务契约)

服务契约 服务契约描述了由服务终结点实现的接口操作。服务契约引用消息格式并描述它们是怎么被交换的。消息格式更进一步被数据契约和消息契约描述。这一部分主要涉及由服务契约实现的消息交换。 WCF在设计时和运行时使用服务契约。在设计阶段，它们确定应该在WSDL理暴露为终结点的代码的类。一个使用[ServiceContract]标记的类和使用[OperationContract]标记的类中方法在WSDL中暴露以便于它们可以被客户端访问。类以wsdl:service确定，操作以w

2010-09-23 08:21:00 550

翻译第二章契约

在原子和金钱世界中，契约是两个或多个组织以一个已知的价格提供商品和服务的合同。在比特和服务的世界中，契约有类似的功能:它是两个或多个组织之间确定消息交换和消息条款及条件的合同。契约是由服务终结点发送或接收的消息的描述。每一个终结点都由ABCs定义:一个消息发送到的网络上的地址，一个描述消息如何发送的绑定，一个描述消息格式的契约。记住服务实际上是终结点集合，终结点用代码实现了特殊算法。它们可以实现高级别的商业功能，比如进入一个订单履行系统，或者可以更细粒度，比如寻找客户的地址。高级功能一般需要复杂

2010-09-21 21:11:00 512

翻译第一章基础 (续为一个ASMX服务实现一个WCF客户端) 完结

为一个ASMX服务实现一个WCF客户端 WCF客户端可以调用任何基于标准的服务而不用考虑目标宿主环境。在.NET Framework 1.1 上创建的ASMX网络服务是完全兼容的。由WS-I 1.1基本概况定义的标准确保它们可以被WCF调用。 支持工具 就像调用一个WCF服务，你可以使用添加服务引用(ASR)或者Svcutil.exe来创建代理类和配置文件来调用ASMX服务操作。在这些被创建以后，客户端通过实例化代理调用方法来与ASMX网络服务通信。同

2010-09-20 20:20:00 1569

翻译第一章基础 (续在IIS中寄宿服务)

在IIS中寄宿服务一个WCF服务可以在操作系统中运行的任何托管进程中寄宿。服务本身一般并不知道或者关心它是怎么被寄宿的，尽管它可以通过丰富的APIs来找出来。它可以寄宿到一个不被注意的随机器初始化时启动随机器关闭时关掉的Windows 服务上，或者在一个最小化到Windows系统托盘的客户端应用程序。最普通的用法，就是在IIS里托管一个WCF服务。讨论IIS非常合适作为宿主。IIS是Windows的一部分而且有一个重要的已经发布的关于管理，安全和开发应用的知识库。IIS是可扩展的，可信赖的而且是非常安全的。

2010-09-19 18:51:00 1483 3

翻译第一章基础(续完成一个WCF服务客户端)

完成一个WCF服务客户端WCF为客户端提供了丰富的API来使用当需要和服务通信时。通过Service.ServiceModel实现的API处理将.NET类型转换成XML然后从客户端向服务端发送消息。你可以直接用API编程，或者你可以使用工具生成一个代理类和配置文件。在这一部分，我们将首先说明如何使用代码直接调用服务，然后我们将使用工具实现这个过程。前一种方法使用较少的代码并不使用配置文件。后一种方式有更少的依赖性而且在调用时有更好的微控性。有很多种情况当每个解决方案是最好的选择时。完全使用代码写一个WCF客

2010-09-18 19:41:00 1114

翻译第一章基础 (续暴露元数据交换节点)

暴露元数据交换终结点WCF中的元数据是精确描述如何与服务通信的消息。客户端可以向一个运行的服务请求元数据来了解它们要求的终结点和消息格式。在设计时，客户端发送由WS-MetadataExchange 标准定义的消息并接收返回的WSDL。WSDL可以被客户端用来定义一个将要用来在运行时与服务通信的代理类和配置文件。图片1.4显示了这个交流过程。默认的，WCF服务不暴露一个MEX终结点。这意味着没有人能查询到这个服务并知晓如何与它通信。不知道地址，绑定和契约，与服务通信是非常困难的，除非服务被记录到注册表

2010-09-17 19:19:00 1170

转载 SQLite的原子提交原理

SQLite的原子提交原理 摘要： 本文源自：http://www.sqlite.org/atomiccommit.html，2007/11/28的版本 本人正在做一个项目，在项目中定义了自己的文件格式，为了做到停电或程序崩溃不损坏这些文件原有的数据，故针对操作的原子性做一些思考，后来看到sqlite的这篇文章，与自己的实现方式作了一些对比。故顺手在研究此文章的时候将大意译成了中文。毕竟只是一时顺手之作，应该存在不少的误读与错误，请多多包涵，此文章的原

2010-09-17 13:14:00 539

翻译第一章基础 (续更多关于配置文件的内容)

更多配置文件相关内容服务控制文件，web.config 或是 app.config 依赖于服务是如何被寄宿的，它们必须包含一个节点。在这个节点下，服务，绑定，行为，客户端，诊断，扩展，寄宿环境和COM+互操作都可以被特殊设置。最低限度，必须有一个节点用来包含终结点，也至少有一个非基础架构的节点下面。在节点内，ABCs会被定义在每一个终结点上。地址属性定义客户端将要把消息发送到终结点的URI。例如，如果一个服务使用basicHttpBinding,基于HTTP协议的绑定，URI将类似于http://ww

2010-09-17 13:04:00 778

翻译第一章基础 (续通过代码和配置文件写一个WCF服务)

使用代码和配置文件写一个WCF服务 WCF为在配置文件中定义服务属性提供了丰富的支持。你仍然需要为你将要在服务中暴露的特性或者算法编码，但是终结点地址，绑定和行为可以从代码中移动到配置文件中。 通过配置文件定义终结点和行为比通过代码更具扩展性。举例说明，假设实现一个终结点并通过HTTP来通信。在列表1.1中，这是通过调用AddServiceEndpoint以及BasicHttpBinding 完成的。现在假设你将把绑定改为使用WSHttpBinding,

2010-09-16 21:03:00 973

翻译第一章基础 (续使用代码生成WCF服务)

。

2010-09-16 13:09:00 675

翻译第一章基础 (续)

所以客户端代码可以简单的调用一个终结点。代理接口不必与服务签名保持一致，但是代理需要确保传输给服务的消息就是服务契约所描述的。app.config 文件包含了特殊绑定。实现一个WCF服务这一部分描述怎么样使用WCF实现一个简单的服务。最简单的方式，我们将使用HTTP 协议，我们将使用文本形式的XML文档。对于安全，我们假设它已经在应用程序中进行了相关处理。我们使用了同步请求-回复方式而且我们的服务只支持一个操作，就是接受输入字符串返回double 型输出。在接下来的章节中，我们会改变所有这些假定，但是目前为

2010-09-15 21:17:00 746 1

翻译第一章基础

微软通信基础是关于服务的。主要是指创建，寄宿，使用以及安全性。WCF是基于标准和互通性的。可以提高开发人员的生产力。简短的说，WCF就是让每一个专业软件开发人员能够使用分布式计算服务。在这一章，我们主要介绍一些了解WCF服务如何工作的基础理论。我们主要集中介绍最通用的特性。通过接下来的内容和例子，你将可以在本地或是网间创建并使用WCF服务。为什么说WCF重要？在深入讨论服务是怎么样的时候，理解为什么更重要。所以，为什么说WCF重要？很简单-因为服务是整个分布式网络的核心

2010-09-12 13:10:00 837 1

翻译章节简介

第一章，“基础”，包括了WCF服务基本的创建和使用。我们讨论并论证如何实现不同的接口以及为什么要选择使用它们。在这一章的最后，你将可以创建并使用WCF服务。 第二章，“契约”，包括了WCF中三种基础契约类型：服务契约，数据契约和消息契约。每一个都可以让我们在代码中定义复杂结构和接口。数据契约映射.NET 类型到XML，服务契约可以在跨平台操作中暴露服务接口终结点以供使用，消息契约可以让开发人员直接在消息中使用XML，而不是使用.NET 类型。对于每一种类型的契约来说，WCF

2010-09-11 21:35:00 495

MusicTown-音庭音乐播放器

空空如也