WCF按照BasicHttpBinding方式发布，部署到服务器上，再在其他项目中引用的时候，就会出现不能正确下载元数据的错误。使用svcutil.exe工具进行测试，出现下面的问题。在Log跟踪中看到： <E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent%22> <System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system
对消息进行签名和加密分别解决了消息的一致性和机密性问题。而最终是仅仅采用签名还是签名与加密共用取决于契约中对消息保护级别的设置。但是具体的签名和加密在整个WCF框架体系中如何实现？是采用对称加密还是非对称加密？密钥如何而来？相信这些问题在本篇文章中你会找到答案。 目录 一、BasicHttpBinding 二、WSHttpBinding、WS2007HttpBinding和WSDualHttpBinding 三、NetTcpBinding和NetNamed
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。为此我们我们写了一个简单的方法，用于列出一个具体的绑定对象所有的绑定元素，在介绍一个个具体的系统绑定中，我会使用该方法： 1: static void ListAllBindingElements(Binding binding) 2: { 3: BindingElementC
WCF是一个具有极高扩展度的分布式通信框架，无论是在信道层（Channel Layer）还是服务模型层（Service Model），我们都可以自定义相关组件通过相应的扩展注入到WCF运行环境中。在WCF众多可扩展点中，ICallContextInitializer可以帮助我们在服务操作执行前后完成一些额外的功能，这实际上就是一种AOP的实现方式。比如在《通过WCF Extension实现Localization》中，我通过ICallContextInitializer确保了服务操作具有和客户端一样的语言文
Artech 已经写过一篇[原创]WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成，在这个解决方案中Unity的侵入性有点强，本文介绍一种具有更少的侵入性的解决方案。 第一步：创建一个自定义的InstanceProvider 来处理WCF服务。 InstanceProvider就是用于创建或者提供service instance的。除了提供service instance的创建者或者提供者的身份外，InstanceProvi
对WCF的可靠会话编程有一定了解的人应该知道，我们可以使用 DeliveryRequirementsAttribute 可以指示WCF确认绑定提供服务或客户端实现所需的功能。如果在从应用程序配置文件加载服务说明或在代码中以编程方式生成服务说明时检测到 DeliveryRequirementsAttribute 属性，则 WCF 会验证所配置的绑定，并支持该属性指定的所有功能。例如，您的服务可能要求绑定支持队列。使用 DeliveryRequirementsAttribute 可以让WCF 确认是否满足下列要
很多WCF的初学者是从之前的Web服务上转移过来的，他们非常怀念.asmx Web服务无配置的服务寄宿方式。你只需要在定义Web服务的时候再表示服务操作的方法上应用WebMethodAttribute特性就可以了，完全可以不需要手工进行相应的配置，因为Web服务运行时会自动为你添加默认的配置。但是对于WCF来说，在进行服务寄宿的时候，你必须以编程或者配置的方式为服务添加至少一个终结点，而终结点需要具备基本的ABC三要素。 对于最新版本的WCF编程人员来说，你也可以采用无配置的服务寄宿了，这主要得益于WCF提
这两天一直在搞typemock的问题，我的同事们都装的最新版7.3 没有问题，只有我老出现下面这个问题。 Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageDat
由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。 一、当异常从服务端抛出 对于一个典型的WCF服务调用，我个人倾向于将潜在抛出的异常费为两种类型：应用异常（Application Exception）和基础结构（Infr
在本篇文章中，我们将通过一个具体的实例来演示如何通过路由服务。在这个例子中，我们会创建连个简单的服务HelloServie和GoodbyeService。假设客户端不能直接调用这两个服务，需要使用到路由服务作为两者之间的中介。整个消息路由的场景如下图所示，中间的GreetingService.svc就是代表路由服务，而两个目标服务则通过HelloServie.svc和GoodbyeService.svc表示。路由服务使用的消息筛选器EndpointAddressMessageFilter，即根据包含在消息中
本篇文章来源于几天前一个朋友向我咨询的问题。问题是这样的，他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿（Hosting），并使用配置的方式对服务的BaseAddress进行了设置，但是在创建ServiceHost的时候却抛出InvalidOperationException，并提示相应Address Scheme的BaseAddress找不到。我意识到这可能和WCF中用于判断服务寄宿方式的逻辑有关，于是我让这位朋友将相同的服务寄宿代码和配置迁移到GUI程序或者Console应用中，看看是
一天，某用户反馈过来说我们的软件无法运行，我一看异常信息看到了这个：“System.Configuration.ConfigurationErrorsException: 无法加载为扩展“Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior”注册的类型“Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior, Microsoft.VisualStudio.Diagnostics.ServiceModelSink, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”。 (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config line 232)”。
是开始学习IronPython 的时候了文章里谈到了“IronPython 2.6提供了新特性clrtype，允许程序员用纯IronPython代码提供property、attribute等CLR类型信息。这样IronPython代码就可以无缝地与Sliverlight、WCF等框架集成。”我们就用clrtype来看看怎么承载WCF服务和消费WCF服务。WCF的契约需要定义接口，这是目前IronPython 尚未支持的功能，所以我们先用C#定义个一个WCF的契约： using System; using
服务契约 [ServiceContract] public interface IService { [OperationContract] string GetData(int value); [OperationContract] string GetString(string value); [OperationContract] void Upload(Request request)
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
对于.NET重载（Overloading）——定义不同参数列表的同名方法（顺便提一下，我们但可以在参数列表上重载方法，我们甚至可以在返回类型层面来重载我们需要的方法——页就是说，我们可以定义两个具有相同参数列表但不同返回值类型的两个同名的方法。不过这种广义的Overloading不被我们主流的.NET 语言所支持的——C#, VB.NET, 但是对于IL来说，这这种基于返回值类型的Overloading是支持的）。相信大家听得耳朵都要起老茧了。我想大家也清楚在编写传统的XML Web Service的时候，
微软北京时间2015.5.20 在其 .NET Foundation GitHub 开源项目页中开放了 WCF 分布式服务框架的代码。WCF突然之间成为一个热门话题，在各大网站上都有不同的报道：dot
通过《再谈IIS与ASP.NET管道》的介绍，相信读者已经对IIS和ASP.NET的请求处理管道有了一个大致的了解，在此基础上去理解基于IIS服务寄宿的实现机制就显得相对容易了。概括地说，基于IIS的服务寄宿依赖于两个重要的对象：System.ServiceModel.Activation.HttpModule和System. ServiceModel.Activation.HttpHandler。 一、通过HttpModule实现服务寄宿 在默认的情况下，基于IIS的服务寄宿是通过一个特殊的HttpMo
对于传统的WCF配置系统，无论是绑定的配置还是行为（服务行为和终结点行为）都必须具有一个名称。而正是通过整个配置名称，它们才能被应用到目标对象（终结点或者服务）上。而在实际的项目开发中，绝大部分服务或者终结点都具有相同的绑定和行为，如果能够定义一种默认的绑定和行为，这无疑会简化我们的配置。WCF4.0为此提供了一个新的特性以支持默认绑定和行为的配置。 一、 默认绑定配置 在传统的配置方式下，如果我们需要对终结点的绑定（不论是系统绑定还是自定义绑定）进行定制，我们都需要配置一个“具名”的绑定，然后将这个名称指
WMI 是基于 Web 的企业管理 (WBEM) 标准的 Microsoft 实现,WCF 公开服务的属性，如地址、绑定、行为和侦听器。您可以在应用程序的配置文件中激活内置 WMI 提供程序。这可以通过 system.ServiceModel element一节中的 <diagnostics> Element的 wmiProviderEnabled 属性实现，如以下配置示例所示。 <system.serviceModel> … <diagnostics wmiProviderEnabled
在《原理篇》我们对客户端如何监听通知，以及服务在上下线时如何发送通知从原理上进行了深入地剖析。我们现在通过一个简单的实例演示如何通过ServiceDiscoveryBehavior服务行为为寄宿的服务添加一个实现上/下线通知的AnnouncementEndpoint终结点，以及客户端如何通过对AnnouncementService服务的寄宿实现对通知的监听和接收。[源代码从这里下载] 我们采用如右图所示的解决方案结构，其中Service.Interface、Service（控制台程序）和Client（控
废话不多说，前两集大致介绍了一下什么是WCF以及和WCF相关的WebService和.net Remoting的一些东西，今天主角要上场，开始WCF的实现相关的东西。
1当客户端调用未返回结果时，服务不可用（网络连接中断，服务关闭，服务崩溃等） 客户端抛出异常 异常类型：CommunicationException InnerException: Message：
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。 服务寄宿的方式大体分两种：一种是为一组WCF服务创建一个托管的应用程序，通过手工启动程序的方式对服务进行寄宿，所有的托管的应用程序均可作为WCF服务的宿主，比如C
通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。 一、 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解，必须对WCF服务端的分发体系有一个清晰的认识。在这里我们先对
Mono 3.0.2 基于双工通信的WCF应用 Demo 的讨论中 深蓝医生 提到了一个问题： 楼主，找了几天，终于明白我的程序错误在哪里了，在服务契约上加入下面的接口方法： [OperationContract] double Sub(double x, double y); 这样客户端调用的时候，能够直接得到Sub方法的返回值，但同样功能的服务在mono 上面运行的时候，出现下面的错误： Unhandled Exception: System.N
当今的IT领域，SOA已经成为了一个非常时髦的词，对SOA风靡的程度已经让很多人对SOA，对面向服务产生误解。其中很大一部分人甚至认为面向服务将是面向对象的终结，现在的面向对象将会被面向服务完全代替。在开始本Blog之前，我先来谈谈我对SOA和OO的区别，首先申明，这只是一家之言，欢迎大家批评指正，并且关于SO的谈论不是本Blog的主题，只是主题的引子，在这里只是简单讨论而已 。 OO和SO之间具有共同的部分，在运用的领域上存在交集，只有在基于他们交集层面上谈论谁是谁非才有意义，下面是我对SO和OO的区别。
今天把PageAdmin Cms建站系统改的一个网站转移到云服务器时候，网站报提示了下面的错误，找了半天在官方网站找到解决办法，下面发出来给大家共享
当在Windows上安装SQL Server，点击setup，出现以下错误0 x84b10001 这个错误是系统文件损坏的原因造成的； 解决办法： 方法1.在命令提示符(管理员)中输入命令 sfc /scannow，确认等待完成；之后在进行安装就可以了； 2. 去C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config配置 寻找机器。配置文件并创建该文件的副本作为备份 右键单击机器。配置并点击Edit(最好使用记事本+ +修改这个文件) 寻找以下部分(搜索< system.serviceModel >)
在本系列的每篇文章中，我多次提到WCF是一个极具可扩展性的分布是消息通信框架。为了让读者对WCF Extension有一个总体的的认识，在这里我会简单列举了我们经常使用的绝大部分的扩展点，以及通过这些扩展点能够解决实现项目开发中的那些问题。 有一点需要特别提醒的是：对WCF extensions的灵活应用依赖于你对channel layer和service mode dispatching system的深入理解。所以，如果你对channel layer不甚了解，可以参阅本系列的第一个部分(WCF是如何通过
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
WCF是.NET平台下实现SOA的一种手段，SOA的一个重要的特征就基于Message的通信方式。从Messaging的角度讲，WCF可以看成是对Message进行发送、传递、接收、基础的工具。对于一个消息交换的过程，很多人只会关注message的最初的发送端和最终的接收端。实际上在很多情况下，在两者之间还存在很多的中间结点（Intermediary），这些中间结点在可能在实际的应用中发挥中重要的作用。比如，我们可以创建路由器（Router）进行消息的转发，甚至是Load Balance；可以创建一个消息拦截器（Interceptor）获取request或者response message，并进行Audit、Logging和Instrumentation。今天我们就我们的目光转向这些充当着中间人角色的Intermediary上面来。
其中<service>节点中的name属性,是实现了服务契约的类型名,类型名必须是完整的,要包括名称空间 <endpoint>节点的address属性为空,说明使用基地址. behaviorConfiguration属性与behavior节点的name属性相匹配 binding属性说明WCF服务使用什么协议,这里是HTTP协议 contract属性是描述契约的接口名称,也必须是完整的.如果没有接口直接写实现契约的类型名也可以(我这里就是这样).
原创地址：http://www.cnblogs.com/jfzhu/p/4044813.html
在Part I 中，我们创建了一个InterceptService，并且通过一个特殊的EndpointBehavior，ClientViaBehavior实现了message的拦截、转发功能。在本节中，我们将讨论另外一种不同的实现方式。如何说ClientViaBehavior是基于Client端的实现方式，那么我们今天讨论的是基于Service的实现方式。
通过上一篇了解了模块内基本的层次划分之后，接下来我们来聊聊PetShop中一些基本基础功能的实现，以及一些设计、架构上的应用如何同WCF进行集成。本篇讨论两个问题：实现分布式的Membership和客户端到服务端上下文（Context）的传递。 一、 如何实现用户验证 对登录用户的验证是大部分应用所必需的，对于ASP.NET来说，用户验证及帐号管理实现在成员资格（Membership）模块中。同ASP.NET的其他模块一样，微软在设计Membership的时候，为了实现更好地可扩展性，采用了策略（Strat
RESTful Wcf是一种基于Http协议的服务架构风格, RESTful 的服务通常是架构层面上的考虑。 因为它天生就具有很好的跨平台跨语言的集成能力，几乎所有的语言和网络平台都支持 HTTP 请求，无需去实现复杂的客户端代理，无需使用复杂的数据通讯方式既可以将我们的服务暴露给任何需要的人，无论他使用 VB、Ruby、JavaScript，甚至是 HTML FORM，或者直接在浏览器地址栏输入
在一个基于面向服务的分布式环境中，借助一个标准的、平台无关的Communication Infrastructure，各个Service通过SOAP Message实现相互之间的交互。这个交互的过程实际上就是Message Exchange的过程。WCF支持不同形式的Message Exchange，我们把这称之为Message Exchange Pattern（MEP）, 常见的MEP包括: Request/Reply，Request/Forget（One-way）和Duplex。通过采用Duplex M
在《基于IIS的WCF服务寄宿（Hosting）实现揭秘》中，我们谈到在采用基于IIS（或者说基于ASP.NET）的WCF服务寄宿中，具有两种截然不同的运行模式：ASP.NET并行（Side by Side）模式和ASP.NET兼容模式。对于前者，WCF通过HttpModule实现了服务的寄宿，而对于后者，WCF的服务寄宿通过一个HttpHandler实现。只有在ASP.NET兼容模式下，我们熟悉的一些ASP.NET机制才能被我们使用，比如通过HttpContext的请求下下文；基于文件或者Url的授权；H
一直觉得SL中的wcf双工通讯方式有点鸡肋，如果是以http方式实现则效率太低，如果用SL4中的tcp方式实现，又跟socket太雷同，所以一直没去研究，不过这东西在对性能要求不高时（比如在网页上每5分钟更新一次天气预报/股票信息），实现起来还是蛮方便的. wcf双工通讯与传统的wcf相比，最大的区别就是：传统的wcf通常都是客户端去调服务，即客户端从服务端上“拉”信息，而双工通讯除了允许客户端从服务端"拉"信息外，服务端还能主动向客户端“推”送信息。 当然这种实现是有性能消耗的，服务端将保存一条"回调通道
本文参考自:http://www.cnblogs.com/wangweimutou/p/4414393.html,纯属读书笔记,加深记忆 一、简介 当我们打开WCF基础客户通道,无论是显示打开还是通过调用操作自动打开、使用客户端或者通过对象调用操作,或者关闭基础客户端通道,都会在客户端应用程序中出现异常,WCF是基于网络的通讯服务,错误异常也是要基于消息传递的,在WCF中提供了一个错误消息处理的类FaultException,WCF客户端可以通过它,来接收服务端传递回来的异常信息。 二、WCF异常类型 1、
我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory<TChannel>创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。从本质上讲，我们只要能够创建于服务端相匹配的终结点，就能够实现正常的服务调用。在WCF客户端元数据架构体系中，利用MetadataExchangeClient可以获取服务的元数据，而利用MetadataImporter将获取的元数据导入成ServiceEndp
无论对于Web Service还是WCF，Client和Service之间交互的唯一形式是通过发送和接收Soap Message。在我们对Web Service和WCF进行深入学习的时候，借助一些Soap Trace 工具对Soap Message进行深入剖析是非常有必要的。在这些工具之中，我觉得最好用的就是Microsoft Soap Toolkit中的Soap Trace Utility和tcpTrace。我们今天就来讲讲如何在WCF中使用tcpTrace这个工具。 首先我们来讲讲tcpTrace实现的
基于HTTP-GET的元数据发布方式与基于WS-MEX原理类似,但是ServiceMetadataBehavior需要做的更多额外的工作。原因很简单，由于在WS-MEX模式下，我们为寄宿的服务添加了相
1、创建WCF客户端应用程序需要执行下列步骤 (1)、获取服务终结点的服务协定、绑定以及地址信息 (2)、使用该信息创建WCF客户端 (3)、调用操作 (4)、关闭WCF客户端对象 二、操作实例 1、
双工（Duplex）模式的消息交换方式体现在消息交换过程中，参与的双方均可以向对方发送消息。基于双工MEP消息交换可以看成是多个基本模式下（比如请求-回复模式和单项模式）消息交换的组合。双工MEP又具有一些变体，比如典型的订阅-发布模式就可以看成是双工模式的一种表现形式。双工消息交换模式使服务端回调（Callback）客户端操作成为可能。 一、两种典型的双工MEP 1．请求过程中的回调 这是一种比较典型的双工消息交换模式的表现形式，客户端在进行服务调用的时候，附加上一个回调对象；服务在对处理该处理中，通过客
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
