VS IDE 中Visual C++ 中的項目屬性配置
一、 Visual C++ 項目系統基於 MSBuild。 雖然可以直接在命令行上編輯 XML 項目文件和屬性表,我們仍建議你使用 VS IDE,在你修改參與繼承的屬性時,這一點尤為重要。 Visual C++ 項目系統不一定可以識別在 MSBuild 中有效的手動編輯文件,在生成過程中可能產生細微錯誤。
項目文件是文件擴展名為 .vcxproj 的 XML 文件。
所有在 IDE 中設置的屬性直接寫入項目文件或生成時導入的屬性表中。
VC++ 目錄是配置屬性,對應不同配置,其值可以不同,例如 Debug 對應 Release。 你可以使用對話框頂部的“配置”和“平台”列表框設置適用於屬性的配置;在許多情況下,“所有平台”和“所有配置”就是合適的選擇。 “通用屬性”規則中的設置適用於所有配置。
當修改后,選擇“確定”按鈕后,新值就會寫入項目文件。
參考:https://msdn.microsoft.com/zh-cn/library/669zx6zc(v=vs.120).aspx
注意:
1. “屬性頁”對話框僅顯示適用於當前項目的屬性頁。 例如,如果該項目沒有 .idl 文件則不會顯示 MIDL 屬性頁。
二、“屬性頁”對話框中屬性的詳細信息
1. “常規”選項頁(項目)
常規
“常規”區域中的屬性影響生成過程中創建的文件位置和當選擇“清除”選項(“生成”菜單)時刪除的文件。
(1)輸出目錄:
指定鏈接器等工具用來放置生成過程中創建的所有最終輸出文件的目錄。
這通常包括鏈接器、管理員或 BSCMake 這類工具的輸出。
對應屬性$(OutDir) , 即 OutputDirectory。
(2)中間目錄
指定編譯器等工具用來放置生成過程中創建的所有中間文件的目錄。
這通常包括 C/C++ 編譯器、MIDL 和資源編譯器這類工具的輸出。
對應屬性$(IntDir) ,即: IntermediateDirectory。
(3)Target Name
此項目生成的文件名
(4)目標擴展名
此項目生成的文件擴展名;例如,.exe 或 .dll
(5)清除時要刪除的擴展名
“清除”選項(“生成”菜單)從生成項目配置的中間目錄中刪除文件。
當運行“清除”或執行重新生成時,具有用此屬性指定的擴展名的文件將被刪除。
除了中間目錄中具有這些擴展名的文件外,生成系統還刪除生成的所有已知輸出(包括 .obj 文件這樣的中間輸出),與它的位置無關。
注意可以指定通配符。
(6)生成日志文件
每次生成項目時創建的日志文件指定非默認位置
默認: $(IntDir)$(MSBuildProjectName).log, 即“中間目錄”/ 項目名稱.log 文件。
(7)平台工具集:
允許項目以 Visual C++ 庫和編譯器的不同版本為目標。
Visual C++ 項目既可以以 Visual Studio 2012 (v100) 中的默認工具集為目標,也可以以創建運行在Windows XP上的可執行程序的工具集為目標。
項目默認值
“項目默認值”區域表示可以修改的默認屬性。
這些屬性的定義可以在 Installation Directory\VC\VCProjectDefaults 中的 .props 文件中找到。
(1)配置類型
-
“應用程序 (.exe)”,顯示鏈接器工具集,該工具集中包括:C/C++ 編譯器、MIDL、資源編譯器、鏈接器、BSCMake、XML Web services 代理生成器、自定義生成、預生成、預鏈接、生成后事件等。
-
“動態庫 (.dll)”,顯示鏈接器工具集,指定 /DLL 鏈接器選項並將 _WINDLL 定義添加到 CL。
-
“Makefile”(生成文件),顯示生成文件工具集 (NMake)。
-
靜態庫 (.lib),顯示管理員工具集(除了用管理員代替鏈接器和省略 XML Web services 代理生成器外,與鏈接器工具集相同)。
-
“Utility”實用工具,顯示實用工具工具集(MIDL、自定義生成、預生成、生成后事件)。
(2)MFC 的使用
指定 MFC 項目是否將靜態或動態鏈接到 MFC DLL。
非 MFC 項目可以選擇“使用標准 Windows 庫”鏈接到使用 MFC 時包括的各種 Win32 庫。
(3)字符集
定義是否應該設置 _UNICODE 或 _MBCS。 在適當的地方還影響鏈接器入口點。
注意: 默認示 Unicode字符集 配置, 如果選擇使用 多字節字符集,則不需要配置Qt的字符選項。
(1)關於“多字節字符集”和“Unicode字符集”的說明:
字符集是一種“字符符號”的集合,同時代表一種編碼形式。但是相同類的字符集有多種“編碼形式”。
早期的VC IDE采用多字節字符集作為默認的設置。由於編譯的軟件適應國際化的需求,因此現在的VS IDE 默認采用 Unicode 字符集。
因此,一般推薦使用Unicode的方式,因為它可以適應各個國家語言,在進行軟件國際時將會非常便得。
(2)關於“多字節字符集”的優點:
(1)適配早期的C++代碼,在VS上編譯
(2)除非在對存儲要求非常高的時候,或要兼容C的代碼時,我們才會使用多字節的方式 。(3)關於Unicode 字符集的優點:
(1)可以很容易地在不同語言之間進行數據交換,適合系統進行“國際化”處理。
(2)提高應用程序的運行效率。
Windows NT是使用Unicode進行開發的,整個系統都是基於Unicode的。(對Multi byte chase Set 多字節版本的API的值對Unicode的封裝,因此,其中添加了轉換的處理,
因此速度比 Unicode版本的調用慢)
如果調用一個API函數並給它傳遞一個ANSI(ASCII字符集以及由此派生並兼容的字符集,如:GB2312,通常稱為ANSI字符集)字符串,那么系統首先要將字符串轉換成Unicode,然后將Unicode字符串傳遞給操作系統。
如果希望函數返回ANSI字符串,系統就會首先將Unicode字符串轉換成ANSI字符串,然后將結果返回給您的應用程序。進行這些字符串的轉換需要占用系統的時間和內存。如果用Unicode來開發應用程序,就能夠使您的應用程序更加有效地運行。(4)字符集的歷史:
參考博客:http://blog.csdn.net/stephen1315/article/details/7476236
最初的時候,Internet 上只有一種字符集——ANSI的ASCII字符集,它使用7 bits來表示一個字符,總共表示128個字符,其中包括了英文字母、數字、標點符號等常用字符。之后,又進行擴展,使用8 bits表示一個字符,可以表示256個字符,主要在原來的7 bits字符集的基礎上加入了一些特殊符號例如制表符。
由於各國語言的加入,ASCII已經不能滿足信息交流的需要。為了能夠表示其它國家的文字,各國在ASCII的基礎上制定了自己的字符集,這些從ANSI標准派生的字符集被習慣的統稱為ANSI字符集,它們正式的名稱應該是MBCS(Multi-Byte Chactacter System,即多字節字符系統)。派生字符集的特點是以ASCII 127 bits為基礎,兼容ASCII 127,他們使用大於128的編碼作為一個Leading Byte,緊跟在Leading Byte后的第二(甚至第三)個字符與Leading Byte一起作為實際的編碼。這樣的字符集有很多,我們常見的GB-2312就是其中之一。
例如在GB-2312字符集中,“連通”的編碼為C1 AC CD A8,其中C1和CD就是Leading Byte。前127個編碼為標准ASCII保留,例如“0”的編碼是30H(30H表示十六進制的30)。軟件在讀取時,如果看到30H,知道它小於128就是標准ASCII,表示“0”,看到C1大於128就知道它后面有一個另外的編碼,因此C1 AC一同構成一個整個的編碼,在GB-2312字符集中表示“連”。
因此,基於 ANSI 編碼擴展而來的 “字符集”,統稱為“多字節字符集”!。 問題:由於ANSI 編碼擴展而來的字符集的編碼規范各不相同,導致最后存在的各種字符集實在太多,在國際交流中要經常轉換字符集非常不便,甚至是編碼字符存在沖突。
為了解決“多字節字符集”的問題,提出了Unicode字符集,它固定使用16 bits(兩個字節、一個字)來表示一個字符,共可以表示65536個字符。將世界上幾乎所有語言的常用字符收錄其中,方便了信息交流。標准的Unicode稱為UTF-16。后來為了雙字節的Unicode能夠在現存的處理單字節的系統上正確傳輸,出現了UTF-8。使用類似多字節字符集編碼MBCS的方式對Unicode進行編碼。注意UTF-8是編碼,它屬於Unicode字符集。
Unicode的最初目標,是用1個16位的編碼來為超過65000字符提供映射。但這還不夠,它不能覆蓋全部歷史上的文字,也不能解決傳輸的問題 (implantation head-ache's),尤其在那些基於網絡的應用中。已有的軟件必須做大量的工作來程序16位的數據。因此,Unicode用一些基本的保留字符制定了三套編碼方式。它們分別是UTF-8,UTF-16和UTF-32。正如名字所示,在UTF-8中,字符是以8位序列來編碼的,用一個或幾個字節來表示一個字符。這種方式的最大好處,是UTF-8保留了ASCII字符的編碼做為它的一部分,例如,在UTF-8和ASCII中,“A”的編碼都是0x41. UTF-16和UTF-32分別是Unicode的16位和32位編碼方式。考慮到最初的目的,通常說的Unicode就是指UTF-16。
例如“連通”兩個字的Unicode標准編碼UTF-16 (big endian)為:DE 8F 1A 90 而其UTF-8編碼為:E8 BF 9E E9 80 9A
因此, “Unicode 字符集”存在多種編碼形式,優點:利於國際化,且由於WinNT操作系統底層都采用Unicode字符編碼,因此,Exe應用采用Unicode編碼,可以加快消息相應,減少內存使用優點。
字符集與字符編碼的系譜圖, 從圖中看出, Unicode字符集包含了:UTF-8, UTF-16, UTF-32等編碼; 而ANSI(多字節字符集)有GBK編碼, ISO8895-1等編碼;
(5)C++基本數據類型中表示字符的有兩種:char、wchar_t區別:
char叫多字節字符(多字節字符集),一個char占一個字節,之所以叫多字節字符是因為它表示一個字時可能是一個字節也可能是多個字節。一個英文字符(如’s’)用一個char(一個字節)表示,一個中文漢字(如’中’)用3個char(三個字節)表示,看下面的例子。
wchar_t被稱為寬字符(是采用Unicode字符集),一個wchar_t占2個字節。之所以叫寬字符是因為所有的字都要用兩個字節(即一個wchar_t)來表示,不管是英文還是中文。看下面的例子:
用法:
多字節字符(char)串常量時用一般的雙引號括起來就可以了。
寬字節字符(wchar_t)串常量時要在引號前加L,如L”String test”
注意:
理解_T()、_Text()宏即L”“ 因為:查看tchar.h頭文件的定義我們知道_T和_TEXT的功能是一樣的,是一個預定義的宏。
#define _T(x) __T(x) #define _TEXT(x) __T(x
我們再看看__T(x)的定義,發現它有兩個:
#ifdef _UNICODE // ... 省略其它代碼 #define __T(x) L ## x // ... 省略其它代碼 #else /* ndef _UNICODE */ // ... 省略其它代碼 #define __T(x) x // ... 省略其它代碼 #endif /* _UNICODE */
當我們的工程的Character Set設置為Use Unicode Character Set時_T和_TEXT就會在常量字符串前面加L,否則(即Use Multi-Byte Character Set時)就會以一般的字符串處理。
VSIDE中設置“Unicode字符集”和“多字節字符集”的對系統的影響:
(1)預定義的影響
當設置為Unicode Character Set時,會有預編譯宏:_UNICODE、UNICODE
在C/C++ 預定義配置中,可以看到:

當設置為Use Multi-Byte Character Set時,會有預編譯宏:_MBCS
(2)對VS 數據類型的影響
多字節字符集(MBCS),與 Unicode字符集 不同設置,對Visual C++ 內置的宏定義影響也不一樣,如下圖:
當設置為MBCS時: TCHAR 則指char(多字節字符類型); LPTSTR 則指代 char*,
當設置為Unicode時: TCHAR 則指wchar_t(多字節字符類型); LPTSTR 則指代 wchar_t*,
其他宏則分別指明了類型:“W”值寬字節 wchar_t, 否則不帶W的,則是“多字節 char類型”
(3)相互轉換方法
- LPWSTR->LPTSTR: W2T();
- LPTSTR->LPWSTR: T2W();
- LPCWSTR->LPCSTR: W2CT();
- LPCSTR->LPCWSTR: T2CW();
- ANSI->UNICODE: A2W();
- UNICODE->ANSI: W2A();
(4)字符串函數:
還有一些字符串的操作函數,它們也有一 一對應關系
一般帶有前綴w(或后綴W)的都是用於寬字符的,而不帶前綴w(或帶有后綴A)的一般是用於多字節字符的。
2. “常規”選項頁(文件)
(1)從生成中排除
指定文件是否應在當前配置的生成中。
(2)內容:
輸出窗口顯示的信息
(3)項目類型:
可以針對該文件,進行“自定義生成工具”。
注意:當設置為“自定義生成工具時”,則左側出現“自定義生成工具選項”
3. “命令行”屬性
大多數屬性頁文件夾都包含“命令行”屬性頁。
該頁顯示在文件夾中設置了哪個屬性。 “命令行”屬性頁還包含一個“附加選項”框,在此框中可以指定對工具有效但在文件夾中沒有相應屬性的屬性。
在編輯框中輸入的任何命令將傳遞給文件夾的工具。 不進行輸入驗證或檢查,也沒有任何依賴項檢查。
4. C++ 調試配置的項目設置
所有和“調試配置”相關的設置:
(1)在“要啟動的調試器”列表框中指定要使用的調試器
選擇將影響屬性的內容變化。
每當您保存解決方案時,每個調試屬性設置均自動寫入並保存到解決方案的“每用戶”文件 (.vcxproj.user) 中。
可選配置如下:
本地 Windows 調試器
遠程 Windows 調試器
Web 瀏覽器調試器
Web 服務調試器
二級設置:
(1)命令(本地 Windows 調試器)
指定在本地計算機上用於啟動要調試程序的命令。
(2)遠程命令(遠程 Windows 調試器)
遠程計算機上的 .exe 的路徑。 可以像在遠程計算機上一樣輸入路徑。
(3)命令參數(本地 Windows 調試器和遠程 Windows 調試器)
為前面指定的命令指定參數![]()
(4)工作目錄
(告訴編譯器調試的exe什么地方)
指定要調試的程序的工作目錄(相對於 EXE 所在的項目目錄)。
如果將此設置保留為空,則工作目錄將為項目目錄。 對於遠程調試,項目目錄將位於遠程服務器上。
(5)附加(本地 Windows 調試器和遠程 Windows 調試器)
指定是啟動應用程序還是附加到應用程序。
默認設置為“否”。
(6)遠程服務器名稱(遠程 Windows 調試器)
指定您要在其上調試應用程序的計算機(不是您的計算機)的名稱(遠程計算機的名稱)
RemoteMachine 生成宏被設置為此屬性的值
(7)連接(遠程 Windows 調試器)
允許您在遠程調試的標准與非身份驗證連接類型之間切換。 在“遠程服務器名稱”框中指定遠程計算機的名稱。 連接類型包括:
帶 Windows 身份驗證的遠程訪問
不帶身份驗證的遠程訪問(僅限本機)
注意 不帶身份驗證的遠程調試可能會使遠程計算機容易受到安全攻擊。 Windows 身份驗證模式更安全。
(8)HTTP URL(Web 服務調試器和 Web 瀏覽器調試器)
指定您要調試的項目所在的 URL。調試Web 服務,以及URL網站Web功能調試。
(9)調試器類型
指定要使用的調試器類型:“僅限本機”、“僅限托管”、“僅限 GPU”、“混合”、“自動”(默認)或“腳本”。
(10)環境(本地 Windows 調試器)
為要調試的程序指定環境變量。
使用標准環境變量語法(例如,PATH="%SystemRoot%\ … …")。
根據“合並環境”設置的不同,這些變量將重寫系統環境或與系統環境合並。
在設置列中單擊時,會出現“編輯…”。 單擊該鏈接可編輯環境變量。
(11)合並環境(本地 Windows 調試器)
確定在“環境”框中指定的變量是否與操作系統定義的環境合並。 默認設置為“是”。
(12)部署目錄(遠程 Windows 調試器)
指定項目輸出在啟動前要被復制的遠程計算機上的路徑。
路徑可以是遠程計算機上的網絡共享,也可以是到遠程計算機上的文件夾的路徑。
默認設置為空,這意味着項目輸出未復制到網絡共享。
若要啟用文件的部署,您還必須在“配置管理器”對話框中選中“部署”復選框。
(13)其他要部署的文件(遠程 Windows 調試器)
如果“部署目錄”屬性已設置,則它是一個要復制到部署目錄中的分號分隔的附加文件列表。
默認設置為空,這意味着不會將其他文件復制到部署目錄中。
若要啟用文件的部署,您還必須在“配置管理器”對話框中選中“部署”復選框。
(14)部署 Visual C++ 調試運行庫(遠程 Windows 調試器)
如果“部署目錄”屬性已設置,則它可以指定當前平台的 Visual C++ 調試運行庫是否應被復制到網絡共享中。 默認設置為“是”。
“C/C++”文件夾(“常規”類別)
調試信息格式 (/Z7、/Zd、/Zi、/ZI)
指定要為項目創建的調試信息類型, 並選擇是將此信息保存在對象(.obj)文件中,還是保存在程序數據庫(PDB)中。
默認選項 (/ZI) 以“編輯並繼續”的兼容格式創建程序數據庫 (PDB)。
選項類型:
/Z{7|i|I}
(1)無 不生成任何調試信息,因此編譯較快。
(2)/ZI(debug 模式下默認選項)
采用支持“編輯並繼續”功能的格式生成程序數據庫(如上所述)。 如果想使用“編輯並繼續”調試,則必須使用此選項。
因為大多數優化與“編輯並繼續”不兼容,所以使用 /ZI 會禁用代碼中的所有 #pragma optimize 語句。
/ZI 會導致在編譯中使用 /Gy(啟用函數級鏈接) 和 /FC(所診斷源代碼文件的完整路徑)。
/ZI 與 /clr(公共語言運行時編譯) 不兼容。(3)/Zi (Release 模式默認選項)
生成一個程序數據庫(PDB),其中包含供調試器使用的類型信息和符號化調試信息。
符號化調試信息包含變量的名稱和類型以及函數和行號。
/Zi 不影響優化。 但是,/Zi 的確暗示了 /debug;
類型信息放置在 .pdb 文件而不是 .obj 文件中。
(4)/Z7
生成包含用於調試器的完整符號調試信息的 .obj 文件。 符號化調試信息包含變量的名稱和類型以及函數和行號。 不生成任何 .pdb 文件。
編譯器將程序數據庫命名為 project.pdb。
如果編譯沒有項目的文件,則編譯器將創建名為 VCx0.pdb. 的數據庫,其中 x 是正在使用的 Visual C++ 的主版本。
編譯器將 PDB 的名稱嵌入每個使用此選項創建的 .obj 文件中,從而使調試器了解符號和行號信息的位置。
當使用此選項時,.obj 文件將較小,因為調試信息存儲在 .pdb 文件中而不是 .obj 文件中。
5. “鏈接器”屬性
常規選項屬性配置
(1)忽略導入庫
默認否。即不忽略導入庫。
Tells the linker not to try to link any .lib output generated from this build into any dependent project.
通知鏈接器不要嘗試將任何從此生成產生的 .lib 輸出鏈接到依賴項目中。 這允許項目系統處理生成時不產生 .lib 文件的 .dll 文件。 如果一個項目依賴另一個產生 DLL 的項目,項目系統將自動鏈接該子項目產生的 .lib 文件。 這對產生 COM DLL 或純資源 DLL 的項目可能不是必需的,這些 DLL 沒有任何具有特定意義的導出。 如果 DLL 沒有導出,鏈接器將不生成 .lib 文件。 如果磁盤上不存在導出 .lib 文件,而項目系統通知鏈接器鏈接此(缺少的)DLL,鏈接將失敗。
使用“忽略導入庫”解決此問題。 當設置為 Yes 時,項目系統將忽略此 .lib 文件是否存在,並使依賴該項目的任何項目不鏈接到不存在的 .lib 文件。
(2)
endl;