昨晚在家上網，看看微軟研究院TechFest 2010的消息，逛逛Channel 9，瞅瞅DevLabs里的項目，以及F#與Reactive Framework之類東西。然而，我一邊對那些有趣而奇妙的技術感嘆不已，同時卻又產生出一種忿忿之情。為什么？因為在國內的技術圈子里，經常有一種在我看來莫名奇妙的鄙視微軟技術的風氣。這樣的風氣在國內的推特圈里也非常明顯，基本上只有我一個人對微軟的技術抱有好感，并“勇于”和大量意見向左的人爭辯。忿忿之余，我便在推特上不斷表達我對這種風氣的抱怨及否定，在這個過程中也基本表達了我在這方面的大部分看法，在這里也進行一番總結總結吧。同時，我也想對微軟社區的許多弟兄講一些話。

      我學習.Net快一年了，偶然間發現大家用的開發工具很多我都沒見過,于是暗中的進行收集（呵呵，夸張了），現在收集滿七種特來做此總結！我稱他們為“七種武器”\(^o^)/

　　許多初學者在使用SQL Server時都會遇到使用SQL Server Management Studio無法連接遠程數據庫實例的問題，大致的錯誤描述如下：

　　一看，又4個月沒發文章了，這4個月除去春節奔波，基本上一直在加班，在中國做程序員總是與外國同行不一樣，起跑線上輸得很厲害。其實按照《人件》統計，程序員一天如果能順流超過3個小時，基本上就可以秒殺絕大多數問題了。問題是在我們現行的工作環境下，經常是一天連一分鐘順流都進入不了，必須是各種打擾，各種打斷，看似提升了效率，事實上是降低了效率。而且，絕大多數時間，我們可能花在了調試錯誤上，而非本身的邏輯問題上。這樣，一天比老外多工作幾個小時——以完成同樣的目的——就是很正常的了。

　　作為一個通信基礎平臺，WCF必須保證通信的可靠性。由于消息交換是WCF采用的通信手段，通信可靠性的保障體現在確保消息的可靠傳輸。WCF本質上是一個消息處理框架，作為整個消息交換系統的兩個終端，即發送端和接收端。換句話說，WCF僅僅負責對消息的發送和接收，一旦消息通過WCF的信道層進入了網絡，就脫離了WCF的控制范圍。但是，由于網絡環境的限制，網絡層不能百分之百地確保對消息的有效交付。如何克服中間環節的制約，確保從一端發送的消息能夠被有效地交付給另一端，這就是可靠消息傳輸（Reliable Messaging）需要解決的問題。WCF通過可靠會話（Reliable Sessions）實現了種種端到端（End to End）的可靠消息傳輸。

　　可能會奇怪為什么有來一個第2號版本，其實，這是改進版本，而這個改進版本實現起來更加容易，更加方便，但是問題也是很明顯的，因為會加上一個100多KB的DLL，對于網頁游戲來說，任何1KB都是寶貴的資源，就為了這個小效果而平白無故增加XAP的容量，也驗證了有得必有失道理，魚與熊掌應該如何取舍呢，先來看看這個實現方式吧。

　　到目前為止，大家都非常推崇魔獸的技能冷卻效果，就是這樣的，我記得群里還對這個效果展開過探討，其實實現起來并不難，關鍵是思路是否正確，這部分我得謝謝豬笨無罪，是他先想出的解決方案，他不愿意寫博客，也就只好我來代勞了，哈哈，后面提供源代碼和預覽，不要錯過。

　　繼續我們的話題吧.自定義控件.如果你還不熟悉自定義控件開發的話,還請看看我以前寫了幾篇,希望對你有幫助

　　理解POCO先要理解POJO

　　理解POCO(Plain Old CLR Object)先要理解POJO。

.NET 4.0讓不同組件之間工作的更好

　　MonoMac是面向Mac OSX API的C#綁定，其API設計主要受到了MonoTouch的啟發，后者可以基于Mono開發原生的iOS應用程序。MonoMac套件的目標之一，也是發布獨立的 .app應用程序，讓最終用戶擺脫對Mono的依賴。MonoTouch的成功則是一個良好的基礎，于是Mono開始將Cocoa API使用C#和.NET世界中的模式與慣例用法表現出來，并提供開發人員整套Cocoa應用程序的開發工具。

契約式編程不是一門嶄新的編程方法論。C/C++ 時代早已有之。Microsoft 在 .NET 4.0 中正式引入契約式編程庫。博主以為契約式編程是一種相當不錯的編程思想，每一個開發人員都應該掌握。它不但可以使開發人員的思維更清晰，而且對于提高程序性能很有幫助。值得一提的是，它對于并行程序設計也有莫大的益處。

　　相關文章：強類型ASP.NET數據綁定改進版、強類型ASP.NET數據綁定改進版之第2版

　　一、概述

1. 摘要

　　在上篇文章中我們看過了如何創建Task，本篇文章就各種類型Task的使用進行說明。