解决方案：WCF客户端无法获取服务端抛出的异常详细信息|C/S框架网
&|&&|&解决方案：WCF客户端无法获取服务端抛出的异常详细信息
解决方案：WCF客户端无法获取服务端抛出的异常详细信息
作者:C/S框架网&&发布日期: 14:20:54
&&解决方案：WCF客户端无法获取服务端抛出的异常详细信息WCF客户端无法获取服务端抛出的异常详细信息，当WCF服务端抛出异常时当前通信channel中止，客户端获取的是下面的信息：跟踪代码该异常是municationObjectFaultedException类型，无法获取具体的错误信息，将导致用户不明白系统究竟出了什么问题。通过跟踪代码，发现在DAL层能辨别异常信息，如下图：但是传到客户端只能取到ServiceChannel通信错误的CommunicationObjectFaultedException异常。原理分析
　　要解释具体的原因，还得从信道（Channel）的两种分类形式说起。在上面一篇文章中，我们就谈到过：WCF通过信道栈实现了消息的编码、传输及 基于某些特殊功能对消息的特殊处理，而绑定对象是信道栈的缔造者，不同的绑定类型创建出来的信道栈具有不同的特性。就对会话的支持来讲，我们可以将信道分 为以下两种：
会话信道（Sessionful Channel）：会话信道确保客户端和服务端之间传输的消息能够相互关联，但是信道的错误（Fault）会影响后续的消息交换； 数据报信道（Datagram Channel）：即使在同一个数据报信道中，每次消息的交换都是相互独立，信道的错误也不会影响后续的消息交换。 　　由于上面的例子中，我们采用了WsHttpBinding，所以在默认条件下创建的信道（Channel）是会话信道（Sessionful Channel）。异常抛出后，当前信道的状态将变成Faulted，表示信道出现错误。错误的信道将不能继续用于后续的通信，即使是调用Close方法试图将其关闭也不行。
解决方案我们在Web服务层用try catch 语法重新封装FaultException异常。
C# Code:public class DataDictService : IDataDictService{&summary& 删除一条数据字典记录 &/summary& &param name="loginTicket"& &param name="keyValue"&主键 &param name="ORM_TypeName"&ORM类型 &returns& public bool Delete(byte[] loginTicket, string keyValue, string ORM_TypeName){&&&try&&&{&&&&&&Loginer loginer = WebServiceSecurity.ValidateLoginer(loginTicket);&&&&&&dalBaseDataDict dict = dalBaseDataDict.CreateDalByORM(loginer, ORM_TypeName); &&&&&&return dict.Delete(keyValue);&&&}&&&catch (Exception ex)&&&{&&&&&&throw new FaultException(ex.Message); &&&&&& FaultException("删除记录发生错误！");//或者提示更具体的异常信息，屏蔽WCF系统内部消息。 &&&}}}
客户端获取FaultException异常成功！&
相关资料：&|&&|&&|&&|&&|&&|&&|&&|&查看: 331|回复: 14
走进WCF一 （异常如此多娇，引无数码农竞折煞） - moonPeng
1分钟注册，结交更多好友，享用更多功能，轻松玩转酷辣虫！
才可以下载或查看，没有帐号？
对于WCF一直都是只知其然，公司框架的架构者也只是对我们授之以鱼，而不授之以渔。
&&带着初学者的态度进入了大神
的博客，逐步慢慢上手。
我的解决方案（和大神的一模一样，只是过程中一波三折的）
& &Clients ：客户端控制台程序，需要引用（System.ServiceMode），并在此项目中创建与WCF的通信。& &
& &Contracts ：契约项目（我是右键解决方案-&添加-&新建项目-&WCF服务库进行创建，这样好像就不用引用System.ServiceMode，它会自动引用），这个项目的就是对外公开的服务层，里面都是接口。& &
& &Hosting ：WCF寄宿控制台程序，主要是搭载WCF服务（和IIS与windows服务性质一样）& &
& &Services ：对Contracts里面方法的实现（也就是WCF方法的实现） ，这个项目是一个类库。& &
Ir6RJv.jpg (12.37 KB, 下载次数: 19)
17:21 上传
起步的项目很简单，就是照抄大神的功能，整个项目结构：
Ir6RJv.jpg (22.1 KB, 下载次数: 9)
17:21 上传
1，契约（Contracts）里面的WCF服务接口
public interface ICalculator{& & & & [OperationContract]& & & & double Add(double x, double y);& & & & [OperationContract]& & & & double Subtract(double x, double y);& & & & [OperationContract]& & & & double Multiply(double x, double y);& & & & [OperationContract]& & & & double Divide(double x, double y);}复制代码2，WCF服务实现库Services，对契约的具体实现
public class CalculatorService : ICalculator{ public double Add(double x, double y) { return x + } public double Subtract(double x, double y) { return x - } public double Multiply(double x, double y) { return x * } public double Divide(double x, double y) { return x / }}复制代码3，宿主项目中对于服务的配置（在控制台程序中新建app.config配置文件进行配置）
& && && && && && & 复制代码4，控制台进行寄宿
using (ServiceHost host = new ServiceHost(typeof(CalculatorService))){& & & & host.Opened += delegate& & & & {& & & & Console.WriteLine(&CalculaorService已经启动，按任意键终止服务！&);& & & & };& & & & host.Open();& & & & Console.Read();}复制代码然后开始了旅程…
糟糕的过程一：将WCF寄宿到控制台
& &Error：【服务“Services.CalculatorService”有零个应用程序(非基础结构)终结点。这可能是因为未找到应用程序的配置文件，或者在配置文件中未找到与服务名称匹配的服务元素，或者服务元素中未定义终结点。】&&
上述错误困扰了我近一个小时，到处找资料Google与百度都瞅遍了，什么样答案都能找到！对我就是木有用。
折腾了许久后，去泡了杯茶，回来后竟然就… 原来折腾我老久的问题是我自己给弄出来的。
&&在将服务给提供服务的主机
ServiceHost
时&&CalculatorService&&是引入了命名空间的，然而在配置文件中进行服务名称配置时确实这样的：
[/code] 当给服务名称 加上命名空间后 就一切正常了 [code]复制代码顿时 ………
Ir6RJv.jpg (11.13 KB, 下载次数: 7)
17:21 上传
糟糕的过程二：客服端建立WCF通信
& &Error：【响应消息的内容类型 text/ charset=utf-8 与绑定(text/ charset=utf-8)的内容类型不匹配。】&&
这个错误也折腾了我许久。错误是说内容类型不匹配，网上说要新建一个绑定
& &复制代码让后在终结点绑定bindingConfiguration
[/code] 照着试了下，完全没有效果，进入反思再反思，想着肯定是不是配置的问题，然后一遍遍检查，破绽便出现了（也怪自己不够细心） 在寄宿控制台的配置文件中绑定的是wsHttpBinding： [code]复制代码而在客服端（Clients）配置文件中绑定的却是basicHttpBinding----&
复制代码解决方案是将客服端（Clients）配置文件改成wsHttpBinding：
public class CalculatorService : ICalculator{ public double Add(double x, double y) { return x + } public double Subtract(double x, double y) { return x - } public double Multiply(double x, double y) { return x * } public double Divide(double x, double y) { return x / }}0复制代码 最后客服端配置文件中的客服端配置为：
public class CalculatorService : ICalculator{ public double Add(double x, double y) { return x + } public double Subtract(double x, double y) { return x - } public double Multiply(double x, double y) { return x * } public double Divide(double x, double y) { return x / }}1复制代码一切准备就绪，接下来开始建立WCF 通信将这些通道将消息发送到不同配置的服务终结点。
public class CalculatorService : ICalculator{ public double Add(double x, double y) { return x + } public double Subtract(double x, double y) { return x - } public double Multiply(double x, double y) { return x * } public double Divide(double x, double y) { return x / }}2复制代码OK ，完事。
上一主题: 下一主题: 本帖标题:本帖地址:
这贴需要挽尊吗
前排支持下了哦~
沙发位出租，有意请联系
看帖回帖一条路！
坚持回帖！
我来一个充满激情的回复
信谎言早该够，得永生！
神马时候我才能升级咧
今天上网不回帖，回帖就回精华帖！
酷辣虫发布的走进WCF一 （异常如此多娇，引无数码农竞折煞） - moonPeng帖子由网友提供或转载于网络，若发布的走进WCF一 （异常如此多娇，引无数码农竞折煞） - moonPeng侵犯了您的权益，请联系我们.
禁止发表任何与中华人民共和国法律有抵触的内容! 如有版权问题请告知删除! 【】所有内容来自用户发布，并不代表的观点。无法对用户发布内容真实性提供任何的保证，请自行验证并承担风险与后果。
Powered by Discuz!
Comsenz Inc.您的位置： &
　　由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。
　　一、当异常从服务端抛出
　　对于一个典型的WCF服务调用，我个人倾向于将潜在抛出的异常费为两种类型：应用异常（Application Exception）和基础结构（Infrastructure Exception）。前者为应用级别，主要体现为执行某个服务操作的业务逻辑抛出的异常；而后者则是业务无关的，通过WCF本身的基础架构抛出，主要体现在对象的序列化、消息的处理、消息传输和消息的分发等等。在这里我们更多地关注与应用异常。
　　首先，我们在不做任何异常处理相关操作的情况下，看看如果在服务端执行某个服务操作的过程中抛出异常后，客户端会得到怎样的结果。我们通过实例的形式来演示这中场景。处于简单和易于理解考虑，我们照例沿用计算服务的例子。
　　我们照例采用典型的四层结构（Contract、Service、Hosting和Client），具体的层次在VS解决方案的划分如图1所示：
图1 异常抛出实例解决方案结构
　　下面代码片断表示服务契约（ICalculator）和服务类型（CalculatorService）的定义。为了简洁，在服务契约接口中，我们仅仅定义了唯一一个用于进行两个整数触发预算的方法Divide。服务契约和服务类型类型分别定义在项目Contracts和Services中。
1: using System.ServiceM
2: namespace Artech.WcfServices.Contracts
[ServiceContract(Namespace = "/")]
public interface ICalculator
[OperationContract]
int Divide(int x, int y);
1: using Artech.WcfServices.C
2: namespace Artech.WcfServices.Services
public class CalculatorService : ICalculator
public int Divide(int x, int y)
return x /
　　接下来是通过Console应用程序（Hosting项目）对上面定义的WCF服务（CalculatorService）进行寄宿（Host）的代码和相关配置。
1: using S
2: using System.ServiceM
3: using Artech.WcfServices.S
4: namespace Artech.WcfServices.Hosting
public class Program
static void Main(string[] args)
using (ServiceHost host = new ServiceHost(typeof(CalculatorService)))
host.Open();
Console.Read();
1: xml version="1.0" encoding="utf-8" ?&
2: &configuration&
&system.serviceModel&
&services&
&service name="Artech.WcfServices.Services.CalculatorService"&
&endpoint address="http://127.0.0.1:3721/calculatorservice" binding="wsHttpBinding" contract="Artech.WcfServices.Contracts.ICalculator" /&
system.serviceModel&
10: configuration&
　　最后在代表客户端的Console应用程序（Client项目）中对计算服务CalculatorService进行调用。相关的服务调用代码和配置如下所示，为了让服务端在执行Divide操作的时候抛出异常，特意将第二个参数设置为0，以便服务在进行除法运算的时候抛出System.DivideByZeroException异常。
1: using S
2: using System.ServiceM
3: using Artech.WcfServices.C
4: namespace Artech.WcfServices.Clients
class Program
static void Main(string[] args)
using (ChannelFactory channelFactory = new ChannelFactory(
"calculatorservice"))
ICalculator calculator = channelFactory.CreateChannel();
using (calculator as IDisposable)
int result = calculator.Divide(1, 0);
1: xml version="1.0" encoding="utf-8" ?&
2: &configuration&
&system.serviceModel&
&endpoint address="http://127.0.0.1:3721/calculatorservice"
binding="wsHttpBinding" contract="Artech.WcfServices.Contracts.ICalculator" name="calculatorservice" /&
system.serviceModel&
9: configuration&
　　在启动服务寄宿程序（Hosting）后执行客户端服务调用程序，在客户端将会跑出如图2所示的类型为　　System.ServiceModel.FaultException的异常，其错误消息为：
　　&由于内部错误，服务器无法处理该请求。有关该错误的详细信息，请打开服务器上的 IncludeExceptionDetailInFaults (从 ServiceBehaviorAttribute 或从
配置行为)以便将异常信息发送回客户端，或在打开每个 Microsoft .NET Framework 3.0 SDK 文档的跟踪的同时检查服务器跟踪日志。&
图2 客户端捕获从服务端抛出的异常
　　从上面的实例演示中，我们可以获知WCF在默认情况下的异常处理行为：对于服务端抛出的异常（这里主要指应用异常），客户端捕获到的总一个具有相同异常消息的异常。由于异常类型和消息固定不变，对于服务的客户端来说，直接通过捕获到的异常相关的信息是无法确定服务端在执行服务操作的时候遇到的具体的错误是什么。
　　WCF如此设计的一个主要的目的为了安全。原因很简单，由于我们不能保证服务端直接抛出的异常不包含任何敏感信息，所以直接将服务端原始的异常信息暴露给客户端（对于服务提供者来说，该客户端可能使一个不受信任或者部完全受信任的第三方）。
　　二、 异常细节的传输
　　通过上面的介绍，我们已经意识到了：在默认的情况下，如果异常（主要指应用异常）在执行服务操作的过程中抛出，其真正的异常信息并不能被客户端捕获。实际上，服务端具体的异常细节信息仅限于服务端可见，并不会传递到客户端。
　　然后，不论对于开发阶段的调试，还是维护阶段的纠错、排错，如果在客户端调用某个服务操作后能够很直接地获取到从服务端抛出异常的所有细节，这无疑是一件很有价值的事情。那么，WCF能够做到这一点呢？答案是肯定的。
　　实际上，对于细心的读者，看到客户端捕获的FaultException异常的消息，就能从中找到解决方案。消息中指出，如果试图得到服务端具体的错误信息，需要开启IncludeExceptionDetailInFaults这么一个开关。具体来讲，又具有两种等效的方式：配置的方式和应用自定义特性（Custom Attribute）的方式。
　　通过在服务端的配置中，为寄宿的服务定义相应的服务行为（Service Behavior），并把serviceDebug配置项的includeExceptionDetailInFaults属性设为True。具体配置如下所示：
1: xml version="1.0" encoding="utf-8" ?&
2: &configuration&
&system.serviceModel&
&behaviors&
&serviceBehaviors&
&behavior name="serviceDebuBehavior"&
&serviceDebug includeExceptionDetailInFaults="true" /&
serviceBehaviors&
behaviors&
&services&
&service behaviorConfiguration="serviceDebuBehavior" name="Artech.WcfServices.Services.CalculatorService"&
&endpoint address="http://127.0.0.1:3721/calculatorservice" binding="wsHttpBinding"
contract="Artech.WcfServices.Contracts.ICalculator" /&
16: system.serviceModel&
17: configuration&
　　大部分系统自定义服务行为都可以直接通过在服务类型上应用这么一个自定义特性一样，includeExceptionDetailInFaults服务调试（ServiceDebug）行为也不另外。在ServiceBehaviorAttribute中定义了一个IncludeExceptionDetailInFaults属性，当我们将ServiceBehaviorAttribute特性应用到具体的服务类型上的时候，只需将此属性设为true即可。
1: [AttributeUsage(AttributeTargets.Class)]
2: public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior
//其他成员
5: public bool IncludeExceptionDetailInFaults { }
　　所以如果不采用上面的配置，在服务类型CalculatorService上面应用ServiceBehaviorAttribute特性，并进行如下的设置，也可以到达相同的效果。
1: using Artech.WcfServices.C
2: using System.ServiceM
3: namespace Artech.WcfServices.Services
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class CalculatorService : ICalculator
//省略服务成员
　　当IncludeExceptionDetailInFaults被开启的ServiceDebug服务属性通过上述两种方式应用到我们例子中的服务CalculatorService的情况下，运行客户端应用程序，将会捕获包含有错误明细信息的异常，运行的结果如图3所示：
图3 客户端捕获到具有明细信息的异常
　　从图3中，我们可以看出客户端捕获到的实际上是一个泛型的System.ServiceModel.FaultException异常。FaultException继承自FaultException，这两种典型的异常类型在WCF异常处理中具有重要的地位，在本章后续章节中还会重点讲述，在这里先做一点简单的介绍。
　　对于所有从服务端抛出的异常，只有FaultException和直接或间接继承自FaultException的异常才能被序列化，并最终通过消息返回给服务的调用端。FaultException可以通过文本的形式保存相应的错误信息。FaultException在FaultException现有的基础上，增加了一个额外的特性：将错误信息通过一个具体的对象表示，其类型便是范型类型TDetail，该对象可以通过属性Detail设置或者获取。
1: [Serializable]
2: public class FaultException : FaultException
// 其他成员
public FaultException(TDetail detail);
public TDetail Detail { }
　　对于上面例子对应的场景，客户端捕获的异常类型实际上是FaultException& &,也就是说其具体的泛型类型参数为。ExceptionDetail的定义如下：
1: [DataContract]
2: public class ExceptionDetail
// 其他成员
public ExceptionDetail(Exception exception);
[DataMember]
public string HelpLink { private }
[DataMember]
public ExceptionDetail InnerException { private }
[DataMember]
public string Message { private }
[DataMember]
public string StackTrace { private }
[DataMember]
16: public string Type { private }
　　ExceptionDetail是一个数据契约（Data Contract），也就意味ExceptionDetail是一个可以被DataContractSerializer进行序列化的对象。再仔细察看具体的属性成员列表，我想很多读者肯定有一种是曾相识的感觉：是不是和System.Exception的属性成员定义很相似。实际上，ExceptionDetail是WCF专门设计出来用于封装服务端抛出的异常信息的，其个属性HelpLink、InnerException和StackTrace各自和System.Exception的同名属性向对应，而属性Type表示异常的类型。
　　也就是说，对于应用了开启IncludeExceptionDetailInFaults的ServiceDebug服务行为的WCF服务，在执行服务操作抛出的异常信息，可以通过包含在客户端捕获的FaultException异常中的ExceptionDetail对象获取。比如，在下面的代码中，我修改了客户端的代码，将具体的错误信息输出到控制台上：
1: using S
2: using System.ServiceM
3: using Artech.WcfServices.C
4: namespace Artech.WcfServices.Clients
class Program
static void Main(string[] args)
using (ChannelFactory channelFactory = new ChannelFactory(
"calculatorservice"))
ICalculator calculator = channelFactory.CreateChannel();
using (calculator as IDisposable)
int result = calculator.Divide(1, 0);
catch (FaultException ex)
Console.WriteLine("Message:{0}", ex.Detail.Message);
Console.WriteLine("Type:{0}", ex.Detail.Type);
Console.WriteLine("StackTrace:{0}", ex.Detail.StackTrace);
Console.WriteLine("HelpLink:{0}", ex.Detail.HelpLink);
(calculator as ICommunicationObject).Abort();
　　输出结果：
1: Message：试图除以零。
2: Type：System.DivideByZeroException
3: StackTrace：
在 Artech.WcfServices.Services.CalculatorService.Divide(Int32 x, Int32 y) 位置 D:\Demos\Artech.WcfServices\Services\CalculatorService.cs:行号 13
在 SyncInvokeDivide(Object , Object[] , Object[] )
在 System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&; outputs)
在System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc&; rpc)
在 System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
13: HelpLink：
　　注：在catch程序块中，我们通过代码（(calculator as ICommunicationObject).Abort();）将会话信道强行中断。原因在于，对于基于会话信道（Sessionful Channel）的服务调用，服务端抛出的异常会将该信道的状态转变为出错状态（Faulted），处于Faulted状态的会话信道将不能再用于后续的通信，即使你调用Close方法将其关闭。在这种情况下，需要调用Abort方法对其进行强行中止。具体的原理，在《WCF技术剖析（卷1）》的第9章有详细的介绍。
　　对于服务行为SerivceDebug的IncludeExceptionDetailInFaults属性，我需要再次重申一遍：由于会导致敏感信息泄露的潜在危险，一般地我们仅仅在调试的时候才会开启该属性。对于已经发布、付诸使用的服务，这个开关一般是关闭的。实际上，我们从这个服务行为的命名也可以看出，SerivceDebug，也是用于调试服务的服务行为罢了。
　　作者：　　出处： 　　本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
上一篇：下一篇：1、服务“CJ.Demo.Conso.WcfService.EmployeeMngService”有零个应用程序(非基础结构)终结点。这可能是因为未找到应用程序的配置文件，或者在配置文件中未找到与服务名称匹配的服务元素，或者服务元素中未定义终结点。 &service name="CJ.Demo.Conso.WcfService.EmployeeMngService"& 整个类的路径未设置正确
2、IIS部署WCF出现‘当前已禁用此服务的元数据发布’ a)如果用4.0框架需要在IIS中将asp.net版本设置为4.0
b )出现提示原因分析：当机器上安装了asp.net 2.0和4.0时，需分别建立应用程序池，并在部署虚拟目录时分属于不同应用程序池。
&& 1) 建立不同应用池
&& 2) 将4.0虚拟目录应用到4.0的应用程序池
//name属性值必须置空
&behavior name="" &&&&&&&&&& &!-- 将下列元素添加到服务行为配置中。 --&&&&&&&&&& &serviceMetadata httpGetEnabled="true" /&&/behavior&
3、没有与给定的地址“”匹配的协议绑定。协议绑定在 IIS 或 WAS 配置中的站点级别配置。
正确的：address单独放置
&baseAddresses& &add baseAddress="http://localhost:8001/"/& &/baseAddresses& &/host& &endpoint address="HelloService" binding="wsHttpBinding" contract="WCFService.IHelloService"& &/endpoint&
4、如果在配置中将“system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled”设置为 true，则需要终结点指定相对地址。如果在终结点上指定相对侦听 URI，则该地址可以是绝对地址。若要解决此问题，请为终结点“ URI。
解决方法：
&endpoint address="" //此处只拿出终结点地址部分 将终结点address改为空
IIS部署的时候，默认会有一个基地址Baseaddress，这个是根据你WCF服务程序的配置生成的。
如果你打算提供完成的地址格式，但是这个完整的地址格式 和Baseaddress 不匹配，比如端口不一样，就会出错。
address换成“”，目的就是使用默认的Baseaddress+“”。避免了你自己设置的和Baseaddress 不匹配的问题。
5、不允许使用此方法
服务器端方法定义中UriTemplate的路径和客户端访问的方法不一致，必须如下
服务端： [WebInvoke(UriTemplate = "Add", Method = "POST")] 客户端：var urlTemp = "http://localhost:3721/EmployeeMngService.svc/Add"; UriTemplate 的值必须和svc/Add后面的add相同
6、在 ServiceModel 客户端配置部分中，找不到引用协定“ServiceReference1.IEmployeeMng”的默认终结点元素。这可能是因为未找到应用程序的配置文件，或者是因为客户端元素中找不到与此协定匹配的终结点元素 ServiceReference1。EmployeeMngClient em = new ServiceReference1.EmployeeMngClient(); 通过添加引用使用服务时，客户端endpoint终结点contract的设置，不是和服务器的contract相同，而是设置为和引用服务相关ServiceReference1.IEmploye1eMngaddress也不能设为和服务端address相同，而要设置为address=
7、此工厂上启用了手动寻址，因此发送的所有消息都必须进行预寻址。
（这个问题花了我一天时间，网上完全没有解决方案。且服务通过网址访问正常，而通过客户端访问就会出现这个问题，归根结底还是配置问题，暂时不知道为什么这样）
&&&&&client&&&&&&&&endpoint&name="employeeService"&&&&&&&&&&&&&&&&address="http://127.0.0.1:3721/employees"&&&&&&&&&&&&&&&&&&&&&&&&&&&&&binding="webHttpBinding"&&&&&&&&&&&&&&&&&contract="Artech.WcfServices.Service.Interface.IEmployees"/&&&&&&/client&
&&behaviors&&&&&&&&endpointBehaviors&&&&&&&&&&behavior&name="webBehavior"&&&&&&&&&&&&webHttp/&&&&&&&&&&/behavior&&&&&&&&/endpointBehaviors&&&&&&&&&&&&/behaviors&&&&&&client&&&&&&&&endpoint&name="employeeService"&&&&&&&&&&&&&&&&address="http://127.0.0.1:3721/employees"&&&&&&&&&&&&&&&&&behaviorConfiguration="webBehavior"&&&&&&&&&&&&&&&&binding="webHttpBinding"&&&&&&&&&&&&&&&&&contract="Artech.WcfServices.Service.Interface.IEmployees"/&&&&&&/client&
8、部署IIS 返回304.1找不到网页IIS--&虚拟目录--&应用程序设置--&创建应用程序(执行权限选择【脚本和可执行文件】）、应用程序池选择4.0
阅读(...) 评论()}