WCFconfiguration没有configuration文件

有谁知道如何在不使用configuration文件的情况下以编程方式公开WCF服务的一个很好的例子吗？ 我知道服务对象模型现在更加丰富，所以我知道这是可能的。 我只是没有看到如何这样做的例子。 相反，我想看看没有configuration文件的情况下如何消费。

在任何人问之前，我有一个非常具体的需要做这个没有configuration文件。 我通常不会推荐这种做法，但正如我所说，在这种情况下，有一个非常具体的需要。

Answer 1

正如我所发现的，使用不带configuration文件的Web服务非常简单。 您只需创build一个绑定对象和地址对象，并将它们传递给客户端代理的构造函数或通用的ChannelFactory实例。 您可以查看默认的app.config来查看要使用的设置，然后在实例化您的代理的地方创build一个静态帮助器方法：

internal static MyServiceSoapClient CreateWebServiceInstance() { BasicHttpBinding binding = new BasicHttpBinding(); // I think most (or all) of these are defaults--I just copied them from app.config: binding.SendTimeout = TimeSpan.FromMinutes( 1 ); binding.OpenTimeout = TimeSpan.FromMinutes( 1 ); binding.CloseTimeout = TimeSpan.FromMinutes( 1 ); binding.ReceiveTimeout = TimeSpan.FromMinutes( 10 ); binding.AllowCookies = false; binding.BypassProxyOnLocal = false; binding.HostNameComparisonMode = HostNameComparisonMode.StrongWildcard; binding.MessageEncoding = WSMessageEncoding.Text; binding.TextEncoding = System.Text.Encoding.UTF8; binding.TransferMode = TransferMode.Buffered; binding.UseDefaultWebProxy = true; return new MyServiceSoapClient( binding, new EndpointAddress( "http://www.mysite.com/MyService.asmx" ) ); } 

Answer 2

如果您有兴趣消除IIS主机的web.config中的System.ServiceModel部分的使用，我已经发布了一个如何在这里执行的示例（ http://bejabbers2.blogspot.com/2010/02/wcf -zero-config-in-net-35-part-ii.html ）。 我展示了如何自定义一个ServiceHost来创build元数据和wshttpbinding端点。 我用通用的方式来做，不需要额外的编码。 对于那些没有立即升级到.NET 4.0的人来说，这可能是非常方便的。

Answer 3

在这里，这是完整的工作代码。 我认为这会帮助你很多。 我正在search，从来没有find一个完整的代码，这就是为什么我试图把完整的工作代码。 祝你好运。

 public class ValidatorClass { WSHttpBinding BindingConfig; EndpointIdentity DNSIdentity; Uri URI; ContractDescription ConfDescription; public ValidatorClass() { // In constructor initializing configuration elements by code BindingConfig = ValidatorClass.ConfigBinding(); DNSIdentity = ValidatorClass.ConfigEndPoint(); URI = ValidatorClass.ConfigURI(); ConfDescription = ValidatorClass.ConfigContractDescription(); } public void MainOperation() { var Address = new EndpointAddress(URI, DNSIdentity); var Client = new EvalServiceClient(BindingConfig, Address); Client.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.PeerTrust; Client.Endpoint.Contract = ConfDescription; Client.ClientCredentials.UserName.UserName = "companyUserName"; Client.ClientCredentials.UserName.Password = "companyPassword"; Client.Open(); string CatchData = Client.CallServiceMethod(); Client.Close(); } public static WSHttpBinding ConfigBinding() { // ----- Programmatic definition of the SomeService Binding ----- var wsHttpBinding = new WSHttpBinding(); wsHttpBinding.Name = "BindingName"; wsHttpBinding.CloseTimeout = TimeSpan.FromMinutes(1); wsHttpBinding.OpenTimeout = TimeSpan.FromMinutes(1); wsHttpBinding.ReceiveTimeout = TimeSpan.FromMinutes(10); wsHttpBinding.SendTimeout = TimeSpan.FromMinutes(1); wsHttpBinding.BypassProxyOnLocal = false; wsHttpBinding.TransactionFlow = false; wsHttpBinding.HostNameComparisonMode = HostNameComparisonMode.StrongWildcard; wsHttpBinding.MaxBufferPoolSize = 524288; wsHttpBinding.MaxReceivedMessageSize = 65536; wsHttpBinding.MessageEncoding = WSMessageEncoding.Text; wsHttpBinding.TextEncoding = Encoding.UTF8; wsHttpBinding.UseDefaultWebProxy = true; wsHttpBinding.AllowCookies = false; wsHttpBinding.ReaderQuotas.MaxDepth = 32; wsHttpBinding.ReaderQuotas.MaxArrayLength = 16384; wsHttpBinding.ReaderQuotas.MaxStringContentLength = 8192; wsHttpBinding.ReaderQuotas.MaxBytesPerRead = 4096; wsHttpBinding.ReaderQuotas.MaxNameTableCharCount = 16384; wsHttpBinding.ReliableSession.Ordered = true; wsHttpBinding.ReliableSession.InactivityTimeout = TimeSpan.FromMinutes(10); wsHttpBinding.ReliableSession.Enabled = false; wsHttpBinding.Security.Mode = SecurityMode.Message; wsHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate; wsHttpBinding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.None; wsHttpBinding.Security.Transport.Realm = ""; wsHttpBinding.Security.Message.NegotiateServiceCredential = true; wsHttpBinding.Security.Message.ClientCredentialType = MessageCredentialType.UserName; wsHttpBinding.Security.Message.AlgorithmSuite = System.ServiceModel.Security.SecurityAlgorithmSuite.Basic256; // ----------- End Programmatic definition of the SomeServiceServiceBinding -------------- return wsHttpBinding; } public static Uri ConfigURI() { // ----- Programmatic definition of the Service URI configuration ----- Uri URI = new Uri("http://localhost:8732/Design_Time_Addresses/TestWcfServiceLibrary/EvalService/"); return URI; } public static EndpointIdentity ConfigEndPoint() { // ----- Programmatic definition of the Service EndPointIdentitiy configuration ----- EndpointIdentity DNSIdentity = EndpointIdentity.CreateDnsIdentity("tempCert"); return DNSIdentity; } public static ContractDescription ConfigContractDescription() { // ----- Programmatic definition of the Service ContractDescription Binding ----- ContractDescription Contract = ContractDescription.GetContract(typeof(IEvalService), typeof(EvalServiceClient)); return Contract; } } 

Answer 4

在服务器端并不容易

对于客户端，你可以使用ChannelFactory

Answer 5

所有的WCFconfiguration都可以通过编程来完成。 所以有可能在没有configuration文件的情况下创build服务器和客户端。

我推荐Juval Lowy编写的“编程WCF服务”一书，其中包含许多编程configuration示例。

Answer 6

在客户端和服务器端都很容易。 Juval Lowy的书有很好的例子。

至于你对configuration文件的评论，我会说configuration文件是穷人第二个在代码中做的。 当你控制连接到你的服务器的每一个客户端，确保它们被更新，并且用户找不到它们并且改变任何东西时，configuration文件是很好的。 我发现WCFconfiguration文件模型是有限的，devise起来有点困难，而且还是一个维护的噩梦。 总而言之，我认为MS将configuration文件作为默认的处理方式是非常糟糕的决定。

编辑：你不能用configuration文件做的事情之一是用非默认的构造函数创build服务。 这会导致静态/全局variables和单例以及其他types的无意义的WCF。

Answer 7

我在下面的链接中find了关于这个主题的博文，非常有趣。

我喜欢的一个想法是能够传递绑定或行为，或者将XML部分从configuration传递给合适的WCF对象，并让它处理属性的分配 – 目前您不能这样做。

像networking上的其他人一样，我需要使用与我的托pipe应用程序（这是一个.NET 2.0 Windows服务）不同的configuration文件。

http://salvoz.com/blog/2007/12/09/programmatically-setting-wcf-configuration/