源程序最好有.csproj或.vbproj文件，沒有的話，要花些時間調試
下面我以VB.NET做示例講解一下：
從proj我們可以獲取以下有用信息
Settings小節中有很多配置選項，對應一些編譯器選項
<References>小節中是項目的引用，第3方類庫最好用絕對路徑
<Imports>小節中是要導入的一些命名空間
<Files>小節中有項目的所有文件，選取 BuildAction = "Compile"的文件
用vbc測試了一下，很容易，注意以下幾項：
rootnamespace
reference
target
imports
加上bugreport可以將所有的源文件代碼和bug報告輸出。不錯
給你一端編譯示例：
vbc /r:System.dll /r:System.Data.dll /r:System.Drawing.dll /r:System.Web.dll /r:System.Xml.dll /r:bin\Microsoft.ApplicationBlocks.Data.dll /r:bin\ExportTechnologies.WebControls.RTE.dll /imports:Microsoft.VisualBasic /imports:System /imports:System.Collections /imports:System.Configuration /imports:System.Data /imports:System.Drawing /imports:System.Web /imports:System.Web.UI /imports:System.Web.UI.HtmlControls /imports:System.Web.UI.WebControls /imports:MMS /rootnamespace:MMS /t:library /out:Truly.MMS.dll /bugreport:bug.log AssemblyInfo.vb Global.asax.vb HDAdd.aspx.vb HDticketLogAdd.aspx.vb MIS.vb PageBase.vb Utils.vb
如果沒有proj文件，那麼可以用下面的命令獲取：
dir /b *.vb > filelist.txt
csc的使用方法就靠你自己去琢磨了。這樣編譯出來的跟vs是有1點區別的，因為我們很多選項沒有配置，但是經過測試，基本可以正常工作的。
-------------------------------------------------------------------------------------------------------
使用 C# 2.0 命令行編譯器
http://msdn.microsoft.com/zh-cn/library/ms379563(vs.80).aspx#mainSection
摘要：本文分析了使用 C# 命令行編譯器 csc.exe 生成應用程序的過程。同時，還將向讀者介紹很多為 C# 2.0 獨有的編譯器選項，例如，extended/reference 標志和強名稱支持。閱讀完本文的內容之後，您將能夠輕松地在沒有向導的環境中生成單文件程序集和多文件程序集。
適用於：
Microsoft Visual C# 2.0
注 本文假定您熟悉 C# 編程語言和 .NET Framework 的結構。體驗一下使用命令行工具的感覺還將證明很有幫助。
下載 CSCSample.msi 文件。
scsc.exe 帶來的樂趣
幾乎沒有人會否認集成開發環境 (IDE)（例如，Visual Studio 2005 和 Visual C# Express 2005）所提供的能使編程工作變得相當簡單的諸多功能。但是，實際上 IDE 自己通常不能提供對基礎編譯器的所有方面的訪問。例如，Visual Studio 2005 不支持生成多文件程序集。
此外，了解在命令行編譯代碼的過程，對於具有以下特征的用戶可能有用：
偏愛最簡單的生成 .NET Framework 應用程序的方法。
希望揭開 IDE 處理源代碼文件的方法的秘密。
希望利用 .NET 生成實用工具，例如，nant 或 msbuild。
沒有集成開發環境，例如，Visual Studio（但實際上具有免費提供的 .NET Framework SDK）。
正在基於 Unix的系統（在該系統中，命令行是必須使用的工具）上使用 .NET Framework，並且希望更好地了解 Mono 和/或 Portable .NET ECMA 兼容 C# 編譯器。
正在研究當前未集成到 Visual Studio 中的備選 .NET 編程語言。
只是希望擴展他們的 C# 編程語言知識。
如果您屬於上面所述的這些用戶，那麼就忠實於自己的選擇並繼續讀下去吧。
C# 編譯器 csc.exe 提供了大量用於對創建 .NET 程序集的方式進行控制的選項。站在一個較高層次來看，命令行選項屬於下列八個類別之一（表 1）。
表 1. csc.exe 提供的標記的類別
C# 編譯器類別
定義
輸出文件
用於控制所生成的程序集的格式、可選的 XML 文檔文件和強名稱信息的選項。
輸入文件
使用戶可以指定輸入文件和引用的程序集的選項。
資源
用於將任何必需的資源（例如，圖標和字符串表）嵌入到程序集中的選項。
代碼生成
這些選項控制調試符號的生成。
錯誤和警告
控制編譯器處理源代碼錯誤/警告的方式。
語言
啟用/禁用 C# 語言功能（例如，不安全代碼）以及條件編譯符號的定義。
雜項
該類別的最有趣的選項使您可以指定 csc.exe 響應文件。
高級
該類別指定一些更加深奧並且通常不太重要的編譯器選項。
注 1.0 和 1.1 版本的 C# 編譯器中存在的 /incremental 標志現在已過時。
在閱讀本文的過程中，您將了解每個編譯器類別中存在的核心 標志（最重要的詞是核心）。對於大多數開發方案，可以安全地忽略 C# 編譯器的很多高級選項。如果您需要有關本文未予討論的 csc.exe 功能的詳細信息，請盡管放心，您可以參閱 Microsoft Visual Studio 2005 文檔幫助系統（只須從“Search”選項卡中搜索“csc.exe”並深入查閱）。
注 MSDN 文檔也會對您也很所幫助，因為它描述了如何在 Visual Studio（如果可用）內部設置 csc.exe 的特定選項。
在使用任何 .NET SDK 命令行工具（包括 C# 編譯器）之前，需要配置開發計算機以識別它們的存在。最簡單的方法是使用 Start | All Programs | Visual Studio 2005 | Visual Studio Tools 菜單選項，啟動預配置的 Visual Studio 命令提示。這一特定的控制台能夠自動初始化必要的環境變量，而無須您執行任何操作。（Visual Studio .NET 2003 用戶需要啟動他們各自的命令提示）。
注 如果您沒有 Visual Studio，但是已經安裝了 .NET Framework SDK，則可以從 Start | All Programs | Microsoft .NET Framework SDK 2.0 菜單選項啟動預配置的命令提示。
如果您希望從任意的 命令提示使用 .NET 命令行工具，則需要手動更新計算機的 Path 變量。做法是，請右鍵單擊桌面上的 My Computer 圖標並選擇 Properties 菜單選項。從出現的對話框中，單擊位於 Advanced 選項卡下面的 Environment Variables 按鈕。從出現的對話框中，在 System 變量列表框中的當前 Path 變量的結尾添加以下目錄清單（請注意，必須用分號分隔各個條目）：
C:\Windows\Microsoft.NET\Framework\v2.0.40607 C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin
注 上面的列表指向我的當前 .NET 2.0 測試版的路徑。您的路徑可能因 Visual Studio 和/或 .NET SDK 的安裝和版本的不同而略有不同，因此請確保執行完整性檢查。
在更新 Path 變量之後，請立即關閉所有對話框和當前打開的任何 Console 窗口，以便提交設置。您現在應當能夠從任何命令提示執行 csc.exe 和其他 .NET 工具了。要進行測試，請輸入以下命令：
csc -? ildasm -?
如果您看到有大量信息顯示出來，那麼您就可以繼續了。
返回頁首 已經能夠熟練地在命令行工作的用戶在使用 csc.exe 時不會有任何問題，因而可以跳到下一節。但是，如果您使用命令行的次數很有限，那麼請讓我說明一些基本的詳細信息，以便進行必要的准備。
首先，可以使用反斜槓或單個短劃線指定 csc.exe 的選項。其次，在 / 或 - 以及隨後的標志之間具有額外的空格是非法 的。因此，“-help”是完全正確，而“- help”就行不通了。為了加以說明，讓我們使用 help 標志檢查完整的命令行選項集：
csc –help csc /help
如果一切正常，則您應當看到所有可能的標志，如圖 1 所示。
很多選項都提供了簡寫表示法，以便為您節省一些鍵入時間。假設 help 標志的簡寫表示法是 ?，則您可以如下所示列出 csc.exe 的選項：
csc –? csc /?
很多選項都需要附加的修飾，例如，目錄路徑和文件名。這種性質的標志使用冒號將標志與它的修飾分隔開來。例如，/reference 選項要求將 .NET 程序集的名稱包括在程序集清單中：
csc /reference:MyLibrary.dll ...
其他標志在性質上是二元 的，因為它們或者被啟用 (+)，或者被禁用 (-)。二元標志總是默認為它們的禁用狀態，因此您通常只需要使用加號標記。例如，要將所有編譯警告都視為錯誤，可以啟用 warnaserror 標志：
csc /warnaserror+ ...
標志的順序無關緊要，但是在指定輸入文件集合之前，必須列出所有標志的集合。另外值得說明的是，在修飾和它的關聯數據之間具有額外的空格是非法 的。例如，請使用 /reference:MyLibrary.dll，而不要使用 /reference:MyLibrary.dll。
返回頁首 我們將要分析的第一組命令行選項用於指定編譯器輸入（表 2）和控制得到的輸出（表 3）。請注意，下面的表還標記了特定於 C# 2.0 的選項和任何可用的簡寫表示法。
表 2. csc.exe 的以輸入為中心的選項
輸入標志
定義
是否特定於 C# 2.0？
/recurse
通知 csc.exe 編譯位於項目的子目錄結構中的 C# 文件。該標志支持通配符語法。
否
/reference (/r)
用於指定要在當前編譯中引用的外部程序集。
否，但是 2.0 編譯器提供了別名變體。
/addmodule
用於指定要包括在多文件程序集中的模塊。
否
表 3. csc.exe 的以輸出為中心的選項
輸出標志
定義
是否特定於 C# 2.0？
/out
指定要生成的程序集的名稱。如果省略該標志，則輸出文件的名稱基於初始輸入文件的名稱（對於 *.dll 程序集而言）或定義 Main() 方法的類的名稱（對於 *.exe 程序集而言）。
否
/target (/t)
指定要創建的程序集的文件格式。
否
/doc
用於生成 XML 文檔文件。
否
/delaysign
使您可以使用強名稱的延遲簽名生成程序集。
是
/keyfile
指定用於對程序集進行強命名的 *.snk 文件的路徑。
是
/keycontainer
指定包含 *.snk 文件的容器的名稱。
是
/platform
指定必須存在以便承載程序集的 CPU（x86、Itanium、x64 或 anycpu）。默認為 anycpu。
是
也許用途最多的輸入/輸出選項是 /target。該標志通過使用附加的修飾（表 4）告訴編譯器您對生成哪個類型的 .NET 程序集感興趣。
表 4. /target 標志的變體
目標修飾
定義
/target:exe
創建基於控制台的程序集。如果未指定 /target 選項，則這是默認選項。
/target:winexe
創建基於 Windows 窗體的可執行程序集。盡管您可以使用 /target:exe 創建 Windows 窗體應用程序，但控制台窗口將在主窗體的後台隱現。
/target:library
用於生成 .NET 代碼庫 (*.dll)。
/target:module
創建將成為多文件程序集的一部分的模塊。
返回頁首 為了說明使用 csc.exe 的輸入/輸出選項的過程，我們將創建一個強命名的單文件程序集 (MyCodeLibrary.dll)，以定義一個名為 SimpleType 的類類型。為了展示 /doc 選項的作用，我們還將生成一個 XML 文檔文件。
首先，請在驅動器 C 上創建一個名為 MyCSharpCode 的新文件夾。在該文件夾中，創建一個名為 MyCodeLibrary 的子目錄。使用您選擇的文本編輯器（notepad.exe 就完全合乎需要）輸入以下代碼，並將該文件保存為剛剛創建的 C:\MyCSharpCode\MyCodeLibrary 目錄中的 simpleType.cs。
// simpleType.cs
using System;
namespace MyCodeLibrary
{
/// <summary>
/// Simple utility type.
/// </summary>
public class SimpleType
{
/// <summary>
/// Print out select environment information
/// </summary>
public static void DisplayEnvironment()
{
Console.WriteLine("Location of this program: {0}",
Environment.CurrentDirectory);
Console.WriteLine("Name of machine: {0}",
Environment.MachineName);
Console.WriteLine("OS of machine: {0}",
Environment.OSVersion);
Console.WriteLine("Version of .NET: {0}",
Environment.Version);
}
}
}
現在，打開命令提示，並且使用 cd（更改目錄）命令導航到 simpleType.cs 文件的位置 (C:\MyCSharpCode\MyCodeLibrary)：
cd MyCSharpCode\MyCodeLibrary
或
cd C:\MyCSharpCode\MyCodeLibrary
要將該源代碼文件編譯為名為 MyCodeLibrary.dll 的單文件程序集，請指定以下命令集：
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
此時，您應當在應用程序目錄中具有一個全新的 .NET 代碼庫，如圖 2 所示。
當在命令行編譯多個 C# 文件時，可以分別列出每個文件 — 如果您希望編譯包含在單個目錄中的 C# 文件的子集，則這可能有所幫助。假設我們已經創建了另外一個名為 asmInfo.cs 的 C# 代碼文件（保存在同一目錄中），它定義了下列程序集級別屬性以描述我們的代碼庫：
// asmInfo.cs
using System;
using System.Reflection;
// A few assembly level attributes.
[assembly:AssemblyVersion("1.0.0.0")]
[assembly:AssemblyDescription("Just an example library")]
[assembly:AssemblyCompany("Intertech Training")]
要只編譯 simpleType.cs 和 asmInfo.cs 文件，請鍵入：
csc /t:library /out:MyCodeLibrary.dll simpleType.cs asmInfo.cs
正如您可能希望的那樣，csc.exe 支持通配符表示法。因而，要編譯單個目錄中的所有文件，請僅將 *.cs 指定為輸入選項：
csc /t:library /out:MyCodeLibrary.dll *.cs
使用 /recurse 指定子目錄
在創建應用程序時，您肯定喜歡為您的項目創建邏輯目錄結構。您可以通過將代碼文件放到特定的子目錄（\Core、\AsmInfo、\MenuSystem 等等）中對它們進行組織，而不是將多達 25 個文件轉儲到名為 myApp 的單個目錄中。盡管我們的當前示例只包含幾個文件，但假設您將 AsmInfo.cs 文件放到一個名為 \AsmInfo 的新的子目錄（如圖 3 所示）中。
要告訴 C# 編譯器編譯位於根目錄以及 AsmInfo 子目錄中的所有 C# 文件，請使用 /recurse 選項：
csc /t:library /out:MyCodeLibrary.dll /recurse:AsmInfo /doc:myDoc.xml *.cs
這裡，/recurse 已經用特定子目錄的名稱限定。要指定多個子目錄，我們可以再次使用通配符語法。如果我們要將 simpleType.cs 文件移到一個新的名為 Core 的子目錄中，則我們可以用以下命令集編譯所有子目錄中的所有 C# 文件：
csc /t:library /out:MyCodeLibrary.dll /recurse:*.cs
在任何一種情況下，輸出都是相同的。
使用 /doc 生成 XML 文檔文件
SimpleType 類已經配備了各種 XML 元素。就像您很可能知道的那樣，C# 編譯器將使用這些帶有三條斜槓的代碼注釋生成 XML 文檔文件。要告訴 csc.exe 創建這樣的文件，必須提供 /doc 選項，並且用要生成的文件的名稱修飾它：
csc /t:library /out:MyCodeLibrary.dll /recurse:*.cs /doc:myDoc.xml
在應用程序目錄中，您現在應當看到一個名為 myDoc.xml 的新文件。如果您打開該文件，則會發現您的類型以 XML 的形式進行了說明，如圖 5 所示。
注 如果您希望了解 C# XML 代碼注釋的詳細信息，則請參閱文章 XML Comments Let You Build Documentation Directly From Your Visual Studio .NET Source Files。
使 用 /keyfile 建立強名稱
當前示例的最後一項任務是為我們的程序集分配一個強名稱。在 .NET 1.1 下，創建強命名程序集需要使用 [AssemblyKeyFile] 屬性。盡管這樣做就很好了，但 C# 2.0 編譯器現在提供了 /keyfile 標志，以指定強名稱密鑰文件 (*.snk) 的位置。
在驅動器 C 上創建一個名為 MyKeyPair 的新文件夾，然後使用命令提示更改至該目錄。接下來，使用 sn.exe 實用工具的 –k 選項創建一個名為 myKeyPair.snk 的新密鑰對。
sn -k myKeyPair.snk
要使用 csc.exe 對 MyCodeLibrary.dll 進行強命名，請發出以下命令集：
csc /t:library /out:MyCodeLibrary.dll /recurse:*.cs /doc:myDoc.xml /keyfile:C:\MyKeyPair\myKeypair.snk
要驗證該程序集的確具有強名稱，請使用安全實用工具 (secutil.exe) 和 –s 選項顯示強名稱信息：
secutil /sMyCodeLibrary.dll
您應當發現，程序集清單中記錄的公鑰值被顯示為如圖 6 所示的輸出。
C# 2.0 編譯器確實還有其他一些以強名稱為中心的標志（/delaysign 和 /keycontainer），您可能希望在空閒時加以研究。特別地，如果您希望啟用延遲簽名，則請使用 /delaysign 選項。
返回頁首 盡管通過命令行工作時可以體驗到其與生俱來的優勢，但沒有人能夠否認鍵入數十個編譯器選項可能導致手指抽筋和錄入錯誤。為了有助於減輕這兩個問題，C# 編譯器支持使用響應文件。
注 所有命令提示都允許您使用 Up 和 Down 箭頭鍵遍歷以前的命令。
響應文件（它們按照約定采用 *.rsp 文件擴展名）包含您希望供給到 csc.exe 中的所有選項。在創建了該文件以後，您就可以將它的名稱指定為 C# 編譯器的唯一選項。為了便於說明，下面提供了一個將用於生成 MyCodeLibrary.dll 的響應文件（請注意，您可以使用 # 符號指定注釋）。
# MyCodeLibraryArgs.rsp # # These are the options used # to compile MyCodeLibrary.dll # Output target and name. /t:library /out:MyCodeLibrary.dll # Location of C# files. /recurse:*.cs # Give me an XML doc. /doc:myDoc.xml # Give me a strong name as well. /keyfile:C:\MyKeyPair\myKeypair.snk
給定該文件以後，您現在就可以使用 @ 選項指定 MyCodeLibraryArgs.rsp 了：
csc @MyCodeLibraryArgs.rsp
如果您願意，則可以指定多個響應文件：
csc @MyCodeLibraryArgs.rsp @MoreArgs.rsp @EvenMoreArgs.rsp
請記住，按照遇到的順序對響應文件進行處理。因此，以前的文件中的設置可能被以後的文件中的設置重寫。
默認的響應文件和 /noconfig 選項
最後，請記住有一個默認的響應文件 — csc.rsp，它由 csc.exe 在每次編譯期間自動處理。如果您分析該文件（它與 csc.exe 本身位於相同的文件夾中）的內容，則您將只是發現一組經常引用的程序集（System.Windows.Forms.dll、System.Data.dll 等等）。
在您希望禁止包括 csc.rsp 的極少數的場合中，您可以指定 /noconfig 標志：
csc /noconfig @MyCodeLibraryArgs.rsp
注 如果您引用程序集，而實際上並不使用它，則它將不會在程序集清單中列出。因此，請不要擔心代碼膨脹問題，因為它們根本不存在。
返回頁首 此時，我們已經使用命令行編譯器創建了具有強名稱（並且進行了說明）的單文件代碼庫。現在，我們需要一個客戶端應用程序以便使用它。請在 C:\MyCSharpCode 中創建一個名為 MyClient 的新文件夾。在該文件夾中，創建一個新的 C# 代碼文件 (simpleTypeClient.cs)，該文件從程序的入口點調用靜態的 SimpleType.DisplayEnvironment() 方法：
// simpleTypeClient.cs
using System;
// Namespace in MyCodeLibrary.dll
using MyCodeLibrary;
namespace MyClientApp
{
public class MyApp
{
public static void Main()
{
SimpleType.DisplayEnvironment();
Console.ReadLine();
}
}
}
因為我們的客戶端應用程序要使用 MyCodeLibrary.dll，所以我們需要使用 /reference（或只是使用 /r）選項。該標志很靈活，因為您可以指定所討論的 *dll 的完整路徑，如下所示：
csc /t:exe /r:C:\MyCSharpCode\MyCodeLibrary\MyCodeLibrary.dll *.cs
或者，如果私有程序集的副本與輸入文件位於相同的文件夾中，則可以只指定程序集名稱：
csc /t:exe /r:MyCodeLibrary.dll *.cs
請注意，我沒有指定 /out 選項。給定該條件，csc.exe 基於我們的初始輸入文件 (simpleTypeClient.cs) 創建了一個名稱。此外，已知 /target 的默認行為是生成基於控制台的應用程序，所以 /t:exe 參數是可選的。
在任何情況下，因為 MyCodeLibrary.dll 是私有程序集，所以您需要將該庫的一個副本放到 MyClient 目錄中。在您完成該工作以後，您就能夠執行 simpleTypeClient.exe 應用程序。圖 7 顯示了可能的測試運行。
注 請回憶一下這個問題，不必將具有強名稱的程序集部署到全局程序集緩存 (GAC) 中。實際上，因為強名稱具有天然的安全性方面的好處，所以向每個程序集（無論共享與否）提供強名稱是一種 .NET 最佳策略。
引用多個外部程序集
如果您希望在命令行引用大量程序集，則可以指定多個 /reference 選項。為了說明這一點，假設我們的客戶端應用程序需要使用包含在名為 NewLib.dll 的庫中的類型：
csc /t:exe /r:MyCodeLibrary.dll /r:NewLib.dll *.cs
作為一種稍微簡單一些的替代方法，您可以使用單個 /reference 選項，並且使用分號分隔的列表指定每個程序集：
csc /t:exe /r:MyCodeLibrary.dl;NewLib.dll *.cs
當然，在創作 C# 響應文件時使用相同的語法。
關於 /lib 的簡短說明
在查看 C# 2.0 程序集別名的作用之前，請允許我對 /lib 標志加以簡短說明。該選項可用於將包含由 /reference 選項指定的程序集的目錄告訴給 csc.exe。為了進行說明，假設您具有三個位於驅動器 C 的根目錄中的 *.dll 程序集。要指示 csc.exe 在 C:\ 下查找 asm1.dll、asm2.dll 和 asm3.dll，需要發出以下命令集：
csc /lib:c:\ /reference:asm1.dll;asm2.dll;asm3.dll *.cs
如果您未使用 /lib，則需要將這三個 .NET 代碼庫手動復制到包含輸入文件的目錄中。還請注意，如果在給定的命令集中多次發出 /lib 標志，則結果將累積起來。
返回頁首 關於 /reference 選項需要進行的最後一點說明是，在 C# 2.0 中，現在可以為引用的程序集創建別名。通過該功能，可以解決在唯一命名的程序集中包含的名稱完全相同的類型之間存在的名稱沖突問題。
為了說明該功能的實用性，請在 C:\MyCSharpCode 目錄中創建一個名為 MyCodeLibrary2 的新文件夾。將現有的 simpleType.cs 和 AsmInfo.cs 文件的副本放到新目錄中。現在，向 SimpleType 中添加一個能夠顯示客戶端提供的字符串的新方法：
/// <summary>
/// Display a user supplied message.
/// </summary>
public static void PrintMessage(string msg)
{
Console.WriteLine("You said: {0}", msg);
}
編譯這些文件，以創建一個名為 MyCodeLibrary2.dll 的新程序集，如下所示：
csc /t:library /out:MyCodeLibrary2.dll *.cs
最後，將這一新代碼庫的副本放到 MyClient 文件夾（圖 8）中。
現在，如果我們的當前客戶端程序希望引用 MyCodeLibrary.dll 以及 MyCodeLibrary2.dll，則我們執行以下操作：
csc /t:exe /r:MyCodeLibrary.dll;MyCodeLibrary2.dll *.cs
編譯器告訴我們，我們已經引入了名稱沖突，因為這兩個程序集都定義了一個名為 SimpleType 的類：
simpleTypeClient.cs(13,7): error CS0433: The type 'MyCodeLibrary.SimpleType' exists in both 'c:\MyCSharpCode\MyClient\MyCodeLibrary.dll' and 'c:\MyCSharpCode\MyClient\MyCodeLibrary2.dll'
乍看起來，您可能認為可以通過在客戶端代碼中使用完全限定名稱來修復該問題。但是，這樣做無法糾正該問題，因為這兩個程序集定義了相同的完全限定名稱 (MyCodeLibrary。SimpleType)。
使用 /reference 標志的新別名選項，我們可以為引用的每個代碼庫生成唯一的名稱。在我們這樣做之後，我們就可以更新客戶端代碼，以便將某個類型與特定的程序集相關聯。
第一步是修改 simpleTypeClient.cs 文件，以使用我們將通過新的 extern alias 語法在命令行指定的別名：
// Extern alias statements must be
// listed before all other code!
extern alias ST1;
extern alias ST2;
using System;
namespace MyClientApp
{
public class MyApp
{
public static void Main()
{
// Bind assembly to type using the '::' operator.
ST1::MyCodeLibrary.SimpleType.DisplayEnvironment();
ST2::MyCodeLibrary.SimpleType.PrintMessage("Hello!");
Console.ReadLine();
}
}
}
請注意，我們已經使用 C# 2.0 extern alias 語句捕獲了在命令行定義的別名。這裡，ST1（簡單類型 1）是為 MyCodeLibrary.dll 定義的別名，而 ST2 是 MyCodeLibrary2.dll 的別名：
csc /r:ST1=MyCodeLibrary.dll /r:ST2=MyCodeLibrary2.dll *.cs
給定這些別名，請注意 Main() 方法如何使用 C# 2.0 范圍解析運算符 (::) 將程序集別名綁定到類型本身：
// This says "I want the MyCodeLibrary.SimpleType class // that is defined in MyCodeLibrary.dll". ST1::MyCodeLibrary.SimpleType.DisplayEnvironment();
進而，/reference 選項的這一變體可以提供一種避免名稱沖突（當兩個具有唯一名稱的程序集包含名稱完全相同的類型時發生）的方式。
返回頁首 就像您可能已經知道的那樣，多文件程序集提供了一種將單個 .NET 二進制文件分解為多個較小的小文件的方式，這在遠程下載 .NET 模塊時證明很有幫助。多文件程序集的最終效果是讓一組文件像一個單獨引用和進行版本控制的單元那樣工作。
多文件程序集包含一個主 *.dll，它包含程序集清單。該多文件程序集的其他模塊（按照約定，它們采用 *.netmodule 文件擴展名）被記錄在主模塊的清單中，並且由 CLR 按需加載。迄今為止，生成多文件程序集的唯一方式是使用命令行編譯器。
為了說明該過程，請在 C:\MyCSharpCode 目錄中創建一個名為 MultiFileAsm 的新子目錄。我們的目標是創建一個名為 AirVehicles 的多文件程序集。主模塊 (Airvehicles.dll) 將包含單個名為 Helicopter 的類類型（稍後定義）。程序集清單編錄了一個附加模塊 (ufos.netmodule)，該模塊定義了一個名為 UFO 的類類型：
// ufo.cs
using System;
using System.Windows.Forms;
namespace AirVehicles
{
public class UFO
{
public void AbductHuman()
{
MessageBox.Show("Resistance is futile");
}
}
}
要將 ufo.cs 編譯為 .NET 模塊，請指定 /t:module 作為目標類型，這會自動遵循 *.netmodule 命名約定（請回想一下，默認的響應文件自動引用 System.Windows.Forms.dll，因此我們不需要顯式引用該庫）：
csc /t:module ufo.cs
如果您要將 ufo.netmodule 加載到 ildasm.exe 中，您會發現一個記載了該模塊的名稱和外部引用程序集的模塊級別清單（請注意，*.netmodules 沒有指定版本號，因為那是主模塊的工作）：
.assembly extern mscorlib{...}
.assembly extern System.Windows.Forms{...}
.module ufo.netmodule
現在，請創建一個名為 helicopter.cs 的新文件，該文件將用於編譯主模塊 Airvehicles.dll：
// helicopter.cs
using System;
using System.Windows.Forms;
namespace AirVehicles
{
public class Helicopter
{
public void TakeOff()
{
MessageBox.Show("Helicopter taking off!");
}
}
}
假設 Airvehicles.dll 是該多文件程序集的主模塊，則您將需要指定 /t:library 標志。但是，因為您還希望將 ufo.netmodule 二進制文件編碼到程序集清單中，所以您還必須指定 /addmodule 選項：
csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs
如果您要分析 airvehicles.dll 二進制文件內部包含的程序集級別清單（使用 ildasm.exe），則會發現 ufo.netmodule 確實是使用 .file CIL 指令記錄的：
.assembly airvehicles{...}
.file ufo.netmodule
多文件程序集的使用者可以較少關心他們要引用的程序集由大量二進制文件組成這一事實。實際上，在句法上將看起來與使用單文件程序集的行為完全相同。為了使本文變得更有趣一些，讓我們創建一個基於 Windows 窗體的客戶端應用程序。
返回頁首 我們的下一個示例項目將是一個使用 airvehicles.dll多文件程序集的 Windows 窗體應用程序。在 C:\MyCSharpCode 目錄中創建一個名為 WinFormClient 的新的子目錄。創建一個派生自 Form 的類，該類定義了單個 Button 類型，當它被單擊時，將創建 Helicopter 和 UFO 類型，並且調用它們的成員：
using System;
using System.Windows.Forms;
using AirVehicles;
public class MyForm : Form
{
private Button btnUseVehicles = new Button();
public MyForm()
{
this.Text = "My Multifile Asm Client";
btnUseVehicles.Text = "Click Me";
btnUseVehicles.Width = 100;
btnUseVehicles.Height = 100;
btnUseVehicles.Top = 10;
btnUseVehicles.Left = 10;
btnUseVehicles.Click += new EventHandler(btnUseVehicles_Click);
this.Controls.Add(btnUseVehicles);
}
private void btnUseVehicles_Click(object o, EventArgs e)
{
Helicopter h = new Helicopter();
h.TakeOff();
UFO u = new UFO();
u.AbductHuman();
}
private static void Main()
{
Application.Run(new MyForm());
}
}
注 在繼續操作之前，請確保將 airvehicals.dll 和 ufo.netmodule 二進制文件復制到 WinFormClient 目錄中。
要將該應用程序編譯為 Windows 窗體可執行文件，請確保指定 winexe 作為 /target 標志的修飾。請注意，在引用多文件程序集時，只須指定主模塊的名稱：
csc /t:winexe /r:airvehicles.dll *.cs
在運行您的程序並單擊按鈕之後，您就應當看到按照預期顯示的每個消息框。圖 9 顯示了我創建的一個消息框。
返回頁首 下一個議程是分析如何使用 csc.exe 將資源（例如，字符串表或圖像文件）嵌入到 .NET 程序集中。首先，可以使用 /win32Icon 選項指定 Win32 *.ico 文件的路徑。假設您已經將一個名為 HappyDude.ico 的圖標文件放到當前 Windows 窗體應用程序的應用程序目錄中。要將 HappyDude.ico 設置為可執行文件的圖標，請發出以下命令集：
csc /t:winexe /win32icon:HappyDude.ico /r:airvehicles.dll *.cs
此時，應當更新可執行程序集，如圖 10 所示。
除了使用 /win32icon 分配應用程序圖標以外，csc.exe 還提供了三個附加的以資源為中心的選項（表 5）。
表 5. csc.exe 的以資源為中心的選項
csc.exe 的以資源為中心的選項
定義
/resource
將 *.resources 文件內部包含的資源嵌入到當前程序集中。請注意，通過該選項可以“以公共方式”嵌入資源以供所有使用者使用，或者“以私有方式”嵌入資源以便僅供包含程序集使用。
/linkresource
在程序集清單中記錄指向外部資源文件的鏈接，但實際上並不嵌入資源自身。
/win32res
使您可以嵌入存在於舊式 *.res 文件中的資源。
在我們了解如何將資源嵌入到我們的程序集中以前，請讓我對 .NET 平台中的資源的性質進行簡短的介紹。正如您可能已經知道的那樣，.NET 資源開始時通常呈現為一組被記錄為 XML（*.resx 文件）或簡單文本 (*.txt) 的名稱/值對。該 XML/文本文件隨後被轉換為等效的二進制文件，它采用 *.resources 文件擴展名。然後，這些二進制文件被嵌入到程序集中並且被記錄在清單中。當需要以編程方式從該程序集中讀取資源的時候，System.Resources 命名空間會提供很多類型來完成該工作，其中最值得注意的是 ResourceManager 類。
盡管您肯定可以手動創建 *.resx 文件，但您最好使用 resgen.exe 命令行工具（或者，您當然可以使用 Visual Studio .NET 本身）。雖然本文不打算描述 resgen.exe 的全部詳細信息，但是讓我們演練一個簡單的示例。
使用 /resource 嵌入資源
在 MyCSharpCode 下面創建一個名為 MyResourceApp 的新目錄。在該目錄中，使用 notepad.exe 創建一個名為 myStrings.txt 的新文件，並且使其包含您選擇的一些有趣的名稱/值對。例如：
# A list of personal data # company=Intertech Training lastClassTaught=.NET Security lastPresentation=SD East Best Practices favoriteGameConsole=XBox favoriteComic=Cerebus
現在，使用命令提示，通過以下命令將 *.txt 文件轉換為一個基於 XML 的 *.resx 文件：
resgen myStrings.txt myStrings.resx
如果您使用 notepad.exe 打開該文件，則會找到許多描述名稱/值對的 XML 元素，例如：
<data name="company"> <value xml:space="preserve">Intertech Training</value> </data> <data name="lastClassTaught"> <value xml:space="preserve">.NET Security</value> </data>
要將該 *.resx 文件轉換為二進制的 *.resources 文件，只須將文件擴展名作為 resgen.exe 的參數進行更新：
resgen myStrings.resx myStrings.resources
此時，我們具有了一個名為 myStrings.resources 的二進制資源文件。通過 /resource 標志可以達到使用 csc.exe 將該數據嵌入到 .NET 程序集中的目的。假設我們已經創作了位於 MyResourceApp 目錄中的以下 C# 文件 (resApp.cs)：
// This simple app reads embedded
// resources and displays them to the
// console.
using System;
using System.Resources;
using System.Reflection;
public class ResApp
{
private static void Main()
{
ResourceManager rm = new ResourceManager("myStrings",
Assembly.GetExecutingAssembly());
Console.WriteLine("Last taught a {0} class.",
rm.GetString("lastClassTaught"));
}
}
要相對於您的 myStrings.resources 文件編譯該程序集，請輸入以下命令：
csc /resource:myStrings.resources *.cs
因為我尚未指定 /out 標志，所以在該示例中，我們的可執行文件的名稱將基於定義了 Main() 的文件 resApp.exe。如果一切正常，則在執行以後，您應當發現類似於圖 11 的輸出。
我希望您能夠輕松地使用 csc.exe 和所選的文本編輯器創建單文件和多文件 .NET 程序集（帶有資源！）。您已經學習了 csc.exe 的最常見的命令行選項，而本文的其余部分將分析一些不太常用但仍然有幫助的選項。
如果您願意繼續學習，請在 MyCSharpCode 文件夾中創建一個名為 FinalExample 的新目錄。
返回頁首 盡管 C# 編譯器沒有真正預處理代碼，但該語言的確允許我們使用類似於 C 的預處理器符號來定義該編譯器以及與其進行交互。使用 C# 的 #define 語法，可以創建能夠控制應用程序內部的執行路徑的標記。
注 必須在使用任何語句或其他 C# 類型定義之前列出所定義的符號。
為了利用常見的示例，假設您希望定義一個名為 DEBUG 的符號。為此，請創建一個名為 finalEx.cs 的新文件，並將其保存在 MyCSharpCode\FinalExample 目錄中：
// Define a 'preprocessor' symbol named DEBUG.
#define DEBUG
using System;
public class FinalExample
{
public static void Main()
{
#if DEBUG
Console.WriteLine("DEBUG symbol defined");
#else
Console.WriteLine("DEBUG not defined");
#endif
}
}
請注意，在我們使用 #define 定義了符號以後，我們就能夠使用 #if、#else 和 #endif 關鍵字來有條件地檢查和響應該符號。如果您現在編譯該程序，則應當看到在 finalEx.exe 執行時，消息“DEBUG symbol defined”顯示到控制台上：
csc *.cs
但是，如果您注釋掉符號定義：
// #define DEBUG
則輸出將會像您預料的那樣（“DEBUG not defined”）。
在 .NET 程序集的開發和測試期間，在命令行定義符號可能有所幫助。這樣做可以快速地即時指定符號，而不必更新代碼基。為了進行說明，假設您希望在命令行定義 DEBUG 符號，則請使用 /define 選項：
csc /define:DEBUG *.cs
當您再次運行該應用程序時，您應當看到顯示“DEBUG symbol defined”— 即使 #define 語句已經被注釋掉。
返回頁首 即使是最好的程序員，有時也會發現有對他們的代碼基進行調試的需要。盡管我假設大多數讀者更喜歡使用 Visual Studio .NET 進行調試活動，但對 csc.exe 的一些以調試為中心的選項（表 6）進行說明是值得的。
表 6. csc.exe 的以調試為中心的選項
csc.exe 的以調試為中心的選項
定義
/debug
指示 csc.exe 發出一個 *.pdb 文件，以供調試工具（例如，cordbg.exe、dbgclr.exe 或 Visual Studio）使用。
/warnaserror
將所有警告視為嚴重錯誤。
/warn
使您可以指定當前編譯的警告級別（0、1、2、3 或 4）。
/nowarn
使您可以禁用特定的 C# 編譯器警告。
/bugreport
如果應用程序在運行時出現故障，則該選項可生成錯誤日志。該選項將提示您輸入糾正信息以發送到您希望的任何地方（例如，QA 小組）。
要說明 /debug 選項的用法，我們首先需要在我們的 finalEx.cs 代碼文件中插入一些編碼錯誤。請將以下代碼添加到當前的 Main() 方法中：
// Create an array.
string[] myStrings = {"Csc.exe is cool"};
// Go out of bounds.
Console.WriteLine(myStrings[1]);
正如您可以看到的那樣，我們試圖使用越界索引訪問我們的數組的內容。如果您重新編譯和運行該程序，則會得到 IndexOutOfRangeException。盡管我們可以明顯地指出該錯誤，但假如是一個不那麼明顯的更為復雜的錯誤，又該怎麼辦呢？
要調試使用 csc.exe 創建的程序集，第一步是生成包含各種 .NET 調試實用工具所需信息的 *.pdb 文件。為此，請輸入下列命令（它們在功能上是等效的）之一：
csc /debug *.cs csc /debug+ *.cs
此時，您應當在應用程序目錄中看到一個名為 finalEx.pdb 的新文件，如圖 12 所示。
可以根據情況用 full 或 pdbonly 標記限定 /debug 標志。當您指定 /debug:full（它是默認標記）時，將以適當的方式對程序集進行修改，以使其可以附加到當前正在執行的調試器。既然該選項能夠 影響所產生的 .NET 程序集的大小和速度，那麼請確保只在調試過程中指定該選項。因為 full 是 /debug 標志的默認行為，所以上述所有選項在功能上是等效的：
csc /debug *.cs csc /debug+ *.cs csc /debug:full *.cs
另一方面，指定 /debug:pdbonly 可以生成一個 *.pdb 文件，以及一個只能在程序由調試工具直接啟動時進行調試的程序集：
csc /debug:pdbonly *.cs
在任何情況下，既然您具有必需的 *.pdb 文件，那麼您就可以使用許多調試工具（cordbg.exe、dbgclr.exe 或 Visual Studio）調試應用程序。為了不偏離本文的重點介紹命令行這一特征，我們將使用 cordbg.exe 實用工具調試該程序：
cordbg finalEx.exe
在調試會話開始以後，您就可以使用 so（單步執行）命令單步執行每個代碼行了。當您單擊出錯的代碼行時，您可以找到如圖 13 所示的代碼轉儲。
要終止 cordbg.exe 實用工具，請鍵入 exit 並按 Return 鍵。
注 本文的重點不是解釋 .NET 調試工具的用法。如果您希望了解有關在命令行進行調試的過程的更多信息，請在 Visual Studio 幫助系統內查找“cordbg.exe”。
返回頁首 至此，您已經了解了 C# 命令行編譯器的核心選項背後的詳細信息。為了使本文的內容更加完整，表 7 簡要描述了我尚未談論到的其余標志。
表 7. csc.exe 的其余選項
csc.exe 的其余選項
定義
/baseaddress
該選項使您可以指定加載 *.dll 的預期基址。默認情況下，該基址由 CLR 選擇。
/checked
指定溢出數據類型界限的整數運算是否會在運行時導致異常。
/codepage
指定要用於編譯中的所有源代碼文件的代碼頁。
/filealign
該選項控制輸出程序集內部的節大小調整（512、1024、2048、4096 或 8192 字節）。如果目標設備是手持型設備（例如，Pocket PC），則可以使用 /filealign 指定可能存在的最小節。
/langversion
該選項指示編譯器只使用 ISO-1 C# 語言功能，它基本上可以歸結為 C# 1.0 語言功能。
/main
如果當前項目定義了多個 Main() 方法（這在單元測試期間可能有所幫助），則可以使用該標志指定在程序集加載時執行哪個 Main() 方法。
/nostdlib
默認情況下，程序集清單自動引用 mscorlib.dll。指定該選項可以禁止這一行為。
/optimize
當被啟用 (/optimize+) 時，可指示編譯器盡可能生成最小且最快的程序集。該選項會發出還指示 CLR 在運行時優化代碼的元數據。
/platform
該標志告訴編譯器針對 32 位或 64 位處理器優化程序集。一般來說，該選項只在 C# 代碼基使用 P/Invoke 和/或不安全的代碼結構時有用。默認值是“anycpu”。
/unsafe
當被啟用時，該選項使 C# 文件可以聲明不安全的作用范圍，這通常用於操縱 C++ 樣式指針。
/utf8output
該選項告訴編譯器使用 UTF-8 編碼輸出數據。
需要了解的是，對於絕大多數 .NET 項目而言，表 7 中列出的選項只能提供非常少的好處。鑒於此，如果您需要進一步的詳細信息，請參閱 MSDN。
返回頁首 本文向您介紹了使用 C# 命令行編譯器生成程序集的過程。就像您已經了解的那樣，大多數工作可以使用兩個標志 — /target 和 /reference 完成。除了分析 csc.exe 的核心標志以外，本文還解釋了響應文件的好處以及多文件程序集的結構。
盡管本文沒有提供有關 csc.exe 的每個選項的全部詳細信息，但我希望您能夠方便地使用 Visual Studio 2005 文檔了解其余標志。
祝您編碼愉快！
Andrew Troelsen 是一位 Microsoft MVP，他在 Intertech Training 擔任顧問和培訓講師。Andrew 創作了許多著作，其中包括獲獎的 C# and the .NET Platform Second Edition (Apress 2002)。他每月都為（真巧）MacTech 撰寫專欄文章，他在這些文章中研究了如何使用 SSCLI、Portible.NET 和 Mono CLI 分發在基於 Unix 的系統上進行 .NET 開發。
