原文地址：
http://www.infoq.com/news/2012/02/WCF-4.5
Ido Flatow發表了一些列的博客，來講述.NET4.5中關於WCF的更新
鏈接地址：
（有時間的話我會陸續翻譯）
出於削減復雜性的目的，WCF自動生成的配置文件將會變得非常、非常的小。自從第一個版本的WCF以來，開發人員發現他們需要維護一個大概有30個配置節的app.config文件，而這些配置節都可以用默認值來代替。誰都知道刪除這些多余的設置比較好,但不幸的是，誰都沒有學會這一招！在WCF 4.5中配置文件只需要設置綁定的類型和名稱即可！
當然這導致了另一個問題：“我怎么知道這些設置是什么呢？”為了回答這個問題，我們必須知道配置文件后端的代碼（與配置信息相關的代碼），並且配置文件的提示並不在是基於schema的智能提示。如果你正在編輯一個endpoint，你需要知道一個behavior的名字，這個時候開發工具會把可用的behavior的名字都給你列出來。在編譯時一些配置文件的錯誤，如契約類型(contract type)行為名稱(behavior name)的錯誤都會被提示出來。
對於那些直接使用WSDL的開發人員來說，也有好消息。WCF 4.5將會在一個單獨的請求中返回一個完整的WSDL。在此之前，只會包含一部分WSDL，這將需要一系列的XSD文件來匹配這個WSDL。使用?singleWsdl查詢字符串取代?singleWsdl可以使用這個改進
把WCF服務寄宿到系統服務內是完全可行的。但大多數開發人員繼續在IIS下完成大量的工作。為什么呢？因為IIS提供了很多內置的支持功能，比如身份驗證，狀態管理和進程回收等。但在IIS下開發WCF服務仍然有一些限制，微軟也正在解決這些問題。比如：必須通過配置才能解決在兩個地方的身份認證服務，如果他們由於異常而沒有同步，那么這個WCF服務就會停止運行。WCF4.5通過允許服務按IIS的方式來進行身份認證（設置身份認證的方式為“繼承自宿主InheritedFromHost”）除掉了此類型的BUG
不幸的的是這只是一個局部修復，如果IIS激活了多個身份驗證類型，那么客戶端只會知道第一個。當然客戶端開發人員會找到另一種方法解決這個問題：他們可以使用另一種類型重寫這個身份驗證類型。
在為基於HTTPS的服務構造URIs對象時，在WSDL信息中顯示了一個BUG，在.net 4中WCF有自動選擇端口的特性（針對各種類型的綁定，TCP,HTTP等）不幸的是，HTTPS在那是還沒有被包括進來。在.NET4.5中這些疏忽將被糾正。Ido Flatow認為HTTPS 版本是在為主機名做廣告而不是訪問WSDL的宿主名（host name），這些可能將成為使用web form時的問題。
另一個bug是關於WCF傳輸流數據的，Ido Flatow:
當你把WCF服務寄宿在IIS上時，即使你沒有使用asp.net兼容模式，你也一樣會得到asp.net處理管線的一部分。可以在MSDN文檔：WCF服務和ASP.NET（查找PostAuthenticateRequest Event部分）找到相關內容。在.Net 4中，ASP.NET里有一個設計缺陷，對WCF的請求會在ASP.NET中緩沖，這些緩沖行為會引起一些副作用
這不僅僅造成處理請求的延時，更嚴重的是，相當大的一部分內容溢出到硬盤上了。
在WCF 4.5中解決了這個問題。