# C# 互操作性入門系列(二):使用平臺調用調用Win32 函數
**C#互操作系列文章:**
1. [**C#互操作性入門系列(一):C#中互操作性介紹**](http://www.cnblogs.com/zhili/archive/2013/01/14/NetInterop.html)
2. [**C#互操作性入門系列(二):使用平臺調用調用Win32 函數**](http://www.cnblogs.com/zhili/archive/2013/01/21/PInvoke.html)
3. [**C#互操作性入門系列(三):平臺調用中的數據封送處理**](http://www.cnblogs.com/zhili/archive/2013/01/23/DataSend.html)
4. [**C#互操作性入門系列(四):在C# 中調用COM組件**](http://www.cnblogs.com/zhili/archive/2013/01/27/COMInterop.html)
**本專題概要:**
* **引言**
* **如何使用平臺調用Win32 函數——從實例開始**
* **當調用Win32函數出錯時怎么辦?——獲得Win32函數的錯誤信息**
* **小結**
**一、引言**
上一專題對.NET 互操作性做了一個全面的概括,其中講到.NET平臺下實現互操作性有三種技術——平臺調用,C++ Interop和COM Interop,今天在這個專題中將會大家介紹第一種技術,即平臺調用。然而朋友們應該會有這樣的疑問,平臺調用到底有什么用呢? 為什么我們要用平臺調用的技術了?**對于這兩個問題的答案就是——平臺調用可以幫助我們實現在.NET平臺下(也就是指用C#、VB.net語言寫的應用程序下)可以調用非托管函數(指定的是C/C++語言寫的函數)。**這樣如果我們在.NET平臺下實現的功能有現有的C/C++ 函數實現了這樣的功能,這時候我們完全沒必要自己再用托管語言(如C#、vb.net)去實現一個這樣的功能,這時候我們應該想到 “拿來主義”,直接使用平臺調用技術調用C/C++ 實現的函數。然而在實際應用中,使用平臺調用技術來調用Win32 API較為普遍,所以在這個專題中將為大家具體介紹了如何使用平臺調用來調用Win32函數以及調用過程中應該注意的問題,下面就從一個具體的實例開始本專題的介紹。
**二、如何使用平臺調用Win32 函數——從實例開始**
在前一個專題中已經介紹了使用平臺調用來調用非托管函數的步驟:
**(1). 獲得非托管函數的信息,即dll的名稱,需要調用的非托管函數名等信息**
**(2). 在托管代碼中對非托管函數進行聲明,并且附加平臺調用所需要屬性**
**(3). 在托管代碼中直接調用第二步中聲明的托管函數**
然而調用Win32 API函數還有一些問題需要注意的地方, 首先, **因為很多Win32 API函數都有ANSI和Unicode兩個版本,所以在托管代碼聲明時需要指定調用調用函數的版本。** 然而很多Win32 API函數有ANSI和Unicode兩個版本并不是隨便說說的,而是有根據的。大家從調用步驟中可以看出,第一步就需要知道非托管函數聲明,為了找到需要需要調用的非托管函數,可以借助兩個工具——Visual Studio自帶的**dumpbin.exe**和**depends.exe**,dumpbin.exe 是一個命令行工具,可以用于查看從非托管DLL中導出的函數等信息,可以通過打開Visual Studio 2010 Command Prompt(中文版為Visual Studio 命令提示(2010)),然后切換到DLL所在的目錄,輸入 dummbin.exe/exports dllName, 如 **dummbin.exe/exports User32.dll** 來查看User32.dll中的函數聲明,關于更多命令的參數可以參看MSDN; 然而 depends.exe是一個可視化界面工具,大家可以從 “**VS安裝目錄\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Bin\**” 這個路徑找到,然后雙擊 depends.exe 就可以出來一個可視化界面(如果某些人安裝的VS沒有附帶這個工具,也可以從官方網站下載:[http://www.dependencywalker.com/](http://www.dependencywalker.com/)),如下圖:

上圖中 我用紅色標示出 MessageBox 有兩個版本,而MessageBoxA 代表的就是ANSI版本,而MessageBoxW 代筆的就是Unicode版本,這也是上面所說的依據。下面就看看 MessageBox的C++聲明的(更多的函數的定義大家可以從MSDN中找到,這里提供MessageBox的定義在MSDN中的鏈接:[http://msdn.microsoft.com/en-us/library/windows/desktop/ms645505(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/windows/desktop/ms645505(v=vs.85).aspx) ):
現在已經知道了需要調用的Win32 API 函數的定義聲明,下面就依據平臺調用的步驟,在.NET 中實現對該非托管函數的調用,下面就看看.NET中的代碼的:
```
using System;
**// 使用平臺調用技術進行互操作性之前,首先需要添加這個命名空間** using System.Runtime.InteropServices;
namespace 平臺調用Demo
{
class Program
{
// 在托管代碼中對非托管函數進行聲明,并且附加平臺調用所需要屬性
// 在默認情況下,CharSet為CharSet.Ansi
// 指定調用哪個版本的方法有兩種——通過DllImport屬性的CharSet字段和通過EntryPoint字段指定
** // 在托管函數中聲明注意一定要加上 static 和extern 這兩個關鍵字**
[DllImport("user32.dll")]
public static extern int MessageBox1(IntPtr hWnd, String text, String caption, uint type);
// 在默認情況下,CharSet為CharSet.Ansi
[DllImport("user32.dll")]
public static extern int MessageBoxA(IntPtr hWnd, String text, String caption, uint type);
// 在默認情況下,CharSet為CharSet.Ansi
[DllImport("user32.dll")]
public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);
// 第一種指定方式,通過CharSet字段指定
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
public static extern int MessageBox2(IntPtr hWnd, String text, String caption, uint type);
// 通過EntryPoint字段指定
[DllImport("user32.dll", EntryPoint="MessageBoxA")]
public static extern int MessageBox3(IntPtr hWnd, String text, String caption, uint type);
[DllImport("user32.dll", EntryPoint = "MessageBoxW")]
public static extern int MessageBox4(IntPtr hWnd, String text, String caption, uint type);
static void Main(string[] args)
{
// 在托管代碼中直接調用聲明的托管函數
// 使用CharSet字段指定的方式,要求在托管代碼中聲明的函數名必須與非托管函數名一樣
// 否則就會出現找不到入口點的運行時錯誤
//MessageBox1(new IntPtr(0), "Learning Hard", "歡迎", 0);
// 下面的調用都可以運行正確
//MessageBoxA(new IntPtr(0), "Learning Hard", "歡迎", 0);
//MessageBox(new IntPtr(0), "Learning Hard", "歡迎", 0);
// 使用指定函數入口點的方式調用
//MessageBox3(new IntPtr(0), "Learning Hard", "歡迎", 0);
// 調用Unicode版本的會出現亂碼
MessageBox4(new IntPtr(0), "Learning Hard", "歡迎", 0);
}
}
}
```
運行正確的結果為:

從代碼的注釋中可以看出,第一個調用MessageBox1會出現運行時錯誤,然而為什么改調用會出現 “無法在 DLL“user32.dll”中找到名為“MessageBox1”的入口點。”的錯誤呢? 為了知道為什么,這里就需要明白通過CharSet字段指定的這種方式的內部執行行為了。之所以會出現這個錯誤,是因為當指定CharSet為Ansi時,P/Invoke首先會通過根函數名在User32.dll中搜索,即不帶后綴A的函數名MessageBox1 進行搜索,如果找到與跟函數一樣名稱的函數,就調用該函數;
如果沒有找到則使用帶后綴為A的函數MessageBox1A進行搜索,如果找到,則使用該函數,如果還是沒有找到,則會出現 “無法在 DLL“user32.dll”中找到名為“MessageBox1”的入口點。”的錯誤。把CharSet指定為Unicode時,搜索方式是一樣的,只是沒找到根函數時會加W后綴進行搜索的。 從上面的搜索調用函數的過程中可以發現,因為user32.dll中既不存在MessageBox1函數也不存在MessageBox1A函數,所以才會出現調用錯誤。(朋友看到出現錯誤時,應該會有這樣的疑問——我們如何捕捉錯誤來顯示錯誤信息呢?這個疑問將會在下一部分解釋。) 然而使用平臺調用技術中,還需要注意下面4點:
(1). DllImport屬性的**ExactSpelling**字段如果設置為**true**時,則在托管代碼中聲明的函數名必須與要調用的非托管函數名完全一致,因為從[ExactSpelling](http://msdn.microsoft.com/zh-cn/library/system.runtime.interopservices.dllimportattribute.exactspelling(v=vs.100).aspx)字面意思可以看出為 "準確拼寫"的意思,當**ExactSpelling**設置為**true**時,此時會改變平臺調用的行為,此時平臺調用只會根據根函數名進行搜索,而找不到的時候不會添加 A或者W來進行再搜索,. MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45">例如,如果指定 **MessageBox**,則平臺調用將搜索 **MessageBox**,如果它找不到完全相同的拼寫則會出現找不到入口函數的錯誤。 從前面的代碼中可以看出,我們在代碼中并沒有指定 **ExactSpelling** 字段,然而代碼中卻沒有出現調用錯誤,這就說明在C#和托管C++語言中, **ExactSpelling** 默認值就是false的,然而在VB。NET中,**ExactSpelling**的默認值就是true, 所以以上代碼如果轉化為Vb.NET時,就需要顯式指定**ExactSpelling** 字段為false,不然就會出現 “找不到函數入口的錯誤”。 為了讓大家更加容易理解上面的理論,相信大家看到下面一張圖會更加理解 **ExactSpelling**字段的含義的**:**
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45">****
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45"> (2). 如果采用設置CharSet的值來控制調用函數的版本時,則需要在托管代碼中聲明的函數名必須與根函數名一致,否則也會調用出錯,這點從平臺調用過程中可以很好地理解,如果需要調用非托管函數名為 MessageBoxA,而你在托管代碼聲明為 MessageBox1,這樣在搜索過程中明顯就會提示找不到函數名的錯誤, 也就是上面代碼中第一個調用出錯的原因。
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45"> (3). 如果通過指定DllImport屬性的**EntryPoint**字段的方式來調用函數版本時,此時必須相應地指定與之匹配的CharSet設置,意思就是——如果指定EntryPoint為 MessageBoxW,那么必須將CharSet指定為CharSet.Unicode,如果指定EntryPoint為 MessageBoxA,那么必須將CharSet指定為CharSet.Ansi或者不指定,因為 CharSet默認值就是Ansi。**上面代碼MessageBox4的調用之所以會出現亂碼,是因為CharSet指定為Ansi(也是默認值)時, 平臺調用將字符串按照ANSI編碼方式封送到非托管內存中(在.NET 中,字符串的編碼方式默認為Unicode的),即每個字符僅占一個字節,(而對于Unicode編碼的字符串來說,字符串中的每個字符都是使用兩個字節進行編碼的),當非托管函數MessageBoxW開始執行時,它會把該內存中的數據按照Unicode編碼處理,即每兩個字節當做是一個Unicode字符,知道遇到雙字節的‘\0’ 字符結束。所以非托管函數返回的結果也就出現亂碼了。 如果指定EntryPoint 字段的值為MessageBoxA,卻把CharSet字段設置為CharSet.Unicode的情況下,也會出現同樣的亂碼問題,如下圖所示:**
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45">****
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45"> (4). CharSet還有一個可選字段為——CharSet.Auto, 如果把CharSet字段設置為CharSet.Auto,則平臺調用會針對目標操作系統適當地自動封送字符串。Unicode on Windows NT, Windows 2000, Windows XP, and the Windows Server 2003 family; the default is Ansi on Windows 98 and Windows Me." data-guid="275999a6d1aff7e55c2abc3094f769ed">在 Windows NT、Windows 2000、Windows XP 和 Windows Server 2003 系列上,默認值為 Unicode;在 Windows 98 和 Windows Me 上,默認值為 Ansi。Auto, languages may override this default." data-guid="9676c285887e8c44ff8277aed31aadd1">盡管公共語言運行時默認值為 Auto,但使用語言可重寫此默認值。Ansi." data-guid="0cb899b48496e2934a217215e86dfe6a">例如,默認情況下,C# 將所有方法和類型都標記為 Ansi。所以下面的調用一樣也會出現亂碼,原因在第三點中已經解釋了,下面直接附上測試例子和結果:
```
class Program
{
[DllImport("user32.dll", EntryPoint = "MessageBoxA", CharSet = CharSet.Auto)]
public static extern int MessageBox5(IntPtr hWnd, String text, String caption, uint type);
static void Main(string[] args)
{
MessageBox5(new IntPtr(0), "Learning Hard", "歡迎", 0);
}
}
```
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45">Ansi." data-guid="0cb899b48496e2934a217215e86dfe6a">運行結果為:
MessageBox, platform invoke searches for **MessageBox** and fails when it cannot locate the exact spelling." data-guid="f890f75ea0bb3ec1eaa56ed400e56d45">Ansi." data-guid="0cb899b48496e2934a217215e86dfe6a">
**三、當調用Win32函數出錯時怎么辦?——獲得Win32函數的錯誤信息**
前面部分為大家演示了平臺調用的使用以及使用過程需要注意的問題, 當大家了解了這些之后,肯定會有這樣的一個疑問,當調用Win32函數過程中遇到由Win32函數返回的錯誤要怎樣去處理呢? 或者由非托管函數的托管定義導致的錯誤或異常怎么捕捉,就如上面代碼中調用**MessageBox1**出現異常時,如何捕捉并給用于一個友好的提示信息呢?對于這個兩個問題,下面通過兩個具體的例子來演示。
捕捉由托管定義導致的異常演示代碼:
```
class Program
{
// 在托管代碼中對非托管函數進行聲明,并且附加平臺調用所需要屬性
// 在默認情況下,CharSet為CharSet.Ansi
// 指定調用哪個版本的方法有兩種——通過DllImport屬性的CharSet字段和通過EntryPoint字段指定
[DllImport("user32.dll")]
public static extern int MessageBox1(IntPtr hWnd, String text, String caption, uint type);
static void Main(string[] args)
{
try
{
MessageBox1(new IntPtr(0), "Learning Hard", "歡迎", 0);
}
catch (DllNotFoundException dllNotFoundExc)
{
Console.WriteLine("DllNotFoundException 異常發生,異常信息為: " + dllNotFoundExc.Message);
}
catch (EntryPointNotFoundException entryPointExc)
{
Console.WriteLine("EntryPointNotFoundException 異常發生,異常信息為: " + entryPointExc.Message);
}
Console.Read();
}
}
```
運行結果為: 
捕獲由Win32函數本身返回異常的演示代碼如下:
```
using System;
using System.ComponentModel;
// 使用平臺調用技術進行互操作性之前,首先需要添加這個命名空間
using System.Runtime.InteropServices;
namespace 處理Win32函數返回的錯誤
{
class Program
{
// Win32 API
// DWORD WINAPI GetFileAttributes(
// _In_ LPCTSTR lpFileName
//);
// 在托管代碼中對非托管函數進行聲明
[DllImport("Kernel32.dll",**SetLastError**=true,CharSet=CharSet.Unicode)]
public static extern uint GetFileAttributes(string filename);
static void Main(string[] args)
{
// 試圖獲得一個不存在文件的屬性
// 此時調用Win32函數會發生錯誤
GetFileAttributes("FileNotexist.txt");
// 在應用程序的Bin目錄下存在一個test.txt文件,此時調用會成功
//GetFileAttributes("test.txt");
// 獲得最后一次獲得的錯誤
int lastErrorCode = Marshal.GetLastWin32Error();
// 將Win32的錯誤碼轉換為托管異常
//Win32Exception win32exception = new Win32Exception();
Win32Exception win32exception = new Win32Exception(lastErrorCode);
if (lastErrorCode != 0)
{
Console.WriteLine("調用Win32函數發生錯誤,錯誤信息為 : {0}", win32exception.Message);
}
else
{
Console.WriteLine("調用Win32函數成功,返回的信息為: {0}", win32exception.Message);
}
Console.Read();
}
}
}
```
運行結果為: 
要想獲得在調用Win32函數過程中出現的錯誤信息,首先必須將DllImport屬性的SetLastError字段設置為true,只有這樣,平臺調用才會將最后一次調用Win32產生的錯誤碼保存起來,然后會在托管代碼調用Win32失敗后,通過Marshal類的靜態方法GetLastWin32Error獲得由平臺調用保存的錯誤碼,從而對錯誤進行相應的分析和處理。這樣就可以獲得Win32中的錯誤信息了。
上面代碼簡單地演示了如何在托管代碼中獲得最后一次發生的Win32錯誤信息,然而還可以通過調用Win32 API 提供的**FormatMessage**函數的方式來獲得錯誤信息,然而這種方式有一個很顯然的弊端(所以這里就不演示了),當對**FormatMessage**函數調用失敗時,這時候就有可能獲得不正確的錯誤信息,所以,推薦采用.NET提供的Win32Exception異常類來獲得具體的錯誤信息。關于更多的**FormatMessage**函數可以參考MSDN: [http://msdn.microsoft.com/en-us/library/ms679351(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/ms679351(v=vs.85).aspx)
**四、小結**
講到這里,本專題的內容也就介紹完了,本專題只是簡單介紹了使用平臺調用技術來調用Win32函數,然而實際的操作遠遠不是這么簡單的,要掌握平臺調用的技術,還需要大家在工作過程多多實踐。因為在本專題中涉及了一些數據封送一些知識,為了幫助大家更好掌握數據封送處理,在一個專題將為大家帶來平臺調用中的數據封送處理專題。
- C# 基礎知識系列
- C# 基礎知識系列 專題一:深入解析委托——C#中為什么要引入委托
- C# 基礎知識系列 專題二:委托的本質論
- C# 基礎知識系列 專題三:如何用委托包裝多個方法——委托鏈
- C# 基礎知識系列 專題四:事件揭秘
- C# 基礎知識系列 專題五:當點擊按鈕時觸發Click事件背后發生的事情
- C# 基礎知識系列 專題六:泛型基礎篇——為什么引入泛型
- C# 基礎知識系列 專題七: 泛型深入理解(一)
- C# 基礎知識系列 專題八: 深入理解泛型(二)
- C# 基礎知識系列 專題九: 深入理解泛型可變性
- C#基礎知識系列 專題十:全面解析可空類型
- C# 基礎知識系列 專題十一:匿名方法解析
- C#基礎知識系列 專題十二:迭代器
- C#基礎知識 專題十三:全面解析對象集合初始化器、匿名類型和隱式類型
- C# 基礎知識系列 專題十四:深入理解Lambda表達式
- C# 基礎知識系列 專題十五:全面解析擴展方法
- C# 基礎知識系列 專題十六:Linq介紹
- C#基礎知識系列 專題十七:深入理解動態類型
- 你必須知道的異步編程 C# 5.0 新特性——Async和Await使異步編程更簡單
- 全面解析C#中參數傳遞
- C#基礎知識系列 全面解析C#中靜態與非靜態
- C# 基礎知識系列 C#中易混淆的知識點
- C#進階系列
- C#進階系列 專題一:深入解析深拷貝和淺拷貝
- C#進階系列 專題二:你知道Dictionary查找速度為什么快嗎?
- C# 開發技巧系列
- C# 開發技巧系列 使用C#操作Word和Excel程序
- C# 開發技巧系列 使用C#操作幻燈片
- C# 開發技巧系列 如何動態設置屏幕分辨率
- C# 開發技巧系列 C#如何實現圖片查看器
- C# 開發技巧 如何防止程序多次運行
- C# 開發技巧 實現屬于自己的截圖工具
- C# 開發技巧 如何使不符合要求的元素等于離它最近的一個元素
- C# 線程處理系列
- C# 線程處理系列 專題一:線程基礎
- C# 線程處理系列 專題二:線程池中的工作者線程
- C# 線程處理系列 專題三:線程池中的I/O線程
- C# 線程處理系列 專題四:線程同步
- C# 線程處理系列 專題五:線程同步——事件構造
- C# 線程處理系列 專題六:線程同步——信號量和互斥體
- C# 多線程處理系列專題七——對多線程的補充
- C#網絡編程系列
- C# 網絡編程系列 專題一:網絡協議簡介
- C# 網絡編程系列 專題二:HTTP協議詳解
- C# 網絡編程系列 專題三:自定義Web服務器
- C# 網絡編程系列 專題四:自定義Web瀏覽器
- C# 網絡編程系列 專題五:TCP編程
- C# 網絡編程系列 專題六:UDP編程
- C# 網絡編程系列 專題七:UDP編程補充——UDP廣播程序的實現
- C# 網絡編程系列 專題八:P2P編程
- C# 網絡編程系列 專題九:實現類似QQ的即時通信程序
- C# 網絡編程系列 專題十:實現簡單的郵件收發器
- C# 網絡編程系列 專題十一:實現一個基于FTP協議的程序——文件上傳下載器
- C# 網絡編程系列 專題十二:實現一個簡單的FTP服務器
- C# 互操作性入門系列
- C# 互操作性入門系列(一):C#中互操作性介紹
- C# 互操作性入門系列(二):使用平臺調用調用Win32 函數
- C# 互操作性入門系列(三):平臺調用中的數據封送處理
- C# 互操作性入門系列(四):在C# 中調用COM組件
- CLR
- 談談: String 和StringBuilder區別和選擇
- 談談:程序集加載和反射
- 利用反射獲得委托和事件以及創建委托實例和添加事件處理程序
- 談談:.Net中的序列化和反序列化
- C#設計模式
- UML類圖符號 各種關系說明以及舉例
- C#設計模式(1)——單例模式
- C#設計模式(2)——簡單工廠模式
- C#設計模式(3)——工廠方法模式
- C#設計模式(4)——抽象工廠模式
- C#設計模式(5)——建造者模式(Builder Pattern)
- C#設計模式(6)——原型模式(Prototype Pattern)
- C#設計模式(7)——適配器模式(Adapter Pattern)
- C#設計模式(8)——橋接模式(Bridge Pattern)
- C#設計模式(9)——裝飾者模式(Decorator Pattern)
- C#設計模式(10)——組合模式(Composite Pattern)
- C#設計模式(11)——外觀模式(Facade Pattern)
- C#設計模式(12)——享元模式(Flyweight Pattern)
- C#設計模式(13)——代理模式(Proxy Pattern)
- C#設計模式(14)——模板方法模式(Template Method)
- C#設計模式(15)——命令模式(Command Pattern)
- C#設計模式(16)——迭代器模式(Iterator Pattern)
- C#設計模式(17)——觀察者模式(Observer Pattern)
- C#設計模式(18)——中介者模式(Mediator Pattern)
- C#設計模式(19)——狀態者模式(State Pattern)
- C#設計模式(20)——策略者模式(Stragety Pattern)
- C#設計模式(21)——責任鏈模式
- C#設計模式(22)——訪問者模式(Vistor Pattern)
- C#設計模式(23)——備忘錄模式(Memento Pattern)
- C#設計模式總結
- WPF快速入門系列
- WPF快速入門系列(1)——WPF布局概覽
- WPF快速入門系列(2)——深入解析依賴屬性
- WPF快速入門系列(3)——深入解析WPF事件機制
- WPF快速入門系列(4)——深入解析WPF綁定
- WPF快速入門系列(5)——深入解析WPF命令
- WPF快速入門系列(6)——WPF資源和樣式
- WPF快速入門系列(7)——深入解析WPF模板
- WPF快速入門系列(8)——MVVM快速入門
- WPF快速入門系列(9)——WPF任務管理工具實現
- ASP.NET 開發
- ASP.NET 開發必備知識點(1):如何讓Asp.net網站運行在自定義的Web服務器上
- ASP.NET 開發必備知識點(2):那些年追過的ASP.NET權限管理
- ASP.NET中實現回調
- 跟我一起學WCF
- 跟我一起學WCF(1)——MSMQ消息隊列
- 跟我一起學WCF(2)——利用.NET Remoting技術開發分布式應用
- 跟我一起學WCF(3)——利用Web Services開發分布式應用
- 跟我一起學WCF(3)——利用Web Services開發分布式應用
- 跟我一起學WCF(4)——第一個WCF程序
- 跟我一起學WCF(5)——深入解析服務契約 上篇
- 跟我一起學WCF(6)——深入解析服務契約 下篇
- 跟我一起學WCF(7)——WCF數據契約與序列化詳解
- 跟我一起學WCF(8)——WCF中Session、實例管理詳解
- 跟我一起學WCF(9)——WCF回調操作的實現
- 跟我一起學WCF(10)——WCF中事務處理
- 跟我一起學WCF(11)——WCF中隊列服務詳解
- 跟我一起學WCF(12)——WCF中Rest服務入門
- 跟我一起學WCF(13)——WCF系列總結
- .NET領域驅動設計實戰系列
- .NET領域驅動設計實戰系列 專題一:前期準備之EF CodeFirst
- .NET領域驅動設計實戰系列 專題二:結合領域驅動設計的面向服務架構來搭建網上書店
- .NET領域驅動設計實戰系列 專題三:前期準備之規約模式(Specification Pattern)
- .NET領域驅動設計實戰系列 專題四:前期準備之工作單元模式(Unit Of Work)
- .NET領域驅動設計實戰系列 專題五:網上書店規約模式、工作單元模式的引入以及購物車的實現
- .NET領域驅動設計實戰系列 專題六:DDD實踐案例:網上書店訂單功能的實現
- .NET領域驅動設計實戰系列 專題七:DDD實踐案例:引入事件驅動與中間件機制來實現后臺管理功能
- .NET領域驅動設計實戰系列 專題八:DDD案例:網上書店分布式消息隊列和分布式緩存的實現
- .NET領域驅動設計實戰系列 專題九:DDD案例:網上書店AOP和站點地圖的實現
- .NET領域驅動設計實戰系列 專題十:DDD擴展內容:全面剖析CQRS模式實現
- .NET領域驅動設計實戰系列 專題十一:.NET 領域驅動設計實戰系列總結