方法一：
在工程屬性裏面配置，有三個地方要增加，一個是項目配置屬性下的VC++ 目錄中的包含目錄和庫目錄下添加對應的文件夾路徑
，然後再鏈接裏面的輸入填寫庫名稱*.lib
方法二：
利用預編譯命令包含，例如：
#ifdef _WIN64
#pragma message( " 編譯64位的庫 ")
#pragma comment(lib, "64位庫路徑")
#else
#pragma message( " 編譯32位的庫 ")
#pragma comment(lib, "32位庫路徑")
#endif
備註：爲啥選_WIN64，因爲在64位系統下，_WIN64和_WIN32都是被定義過的，在32位系統中只有_WIN32是被定義的
關於VC預定義常量_WIN32，WIN32，_WIN64等預定義宏的介紹（整理、轉載）
方法三：
直接修改用戶屬性文件*.user.vroprj
====華麗的分界線，以下是部分預編譯命令的知識========================================
解析#pragma指令
在所有的預處理指令中，#Pragma 指令可能是最複雜的了，它的作用是設定編譯器的狀態或者是指示編譯器完成一些特定的動作。#pragma指令對每個編譯器給出了一個方法,在保持與C和C++語言完全兼容的情況下,給出主機或操作系統專有的特徵。依據定義,編譯指示是機器或操作系統專有的,且對於每個編譯器都是不同的。
其格式一般爲: #Pragma Para
其中Para 爲參數，下面來看一些常用的參數。
(1)message 參數。 Message 參數是我最喜歡的一個參數，它能夠在編譯信息輸出窗
口中輸出相應的信息，這對於源代碼信息的控制是非常重要的。其使用方法爲：
#Pragma message(“消息文本”)
當編譯器遇到這條指令時就在編譯輸出窗口中將消息文本打印出來。
當我們在程序中定義了許多宏來控制源代碼版本的時候，我們自己有可能都會忘記有沒有正確的設置這些宏，此時我們可以用這條指令在編譯的時候就進行檢查。假設我們希望判斷自己有沒有在源代碼的什麼地方定義了_X86這個宏可以用下面的方法
#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
當我們定義了_X86這個宏以後，應用程序在編譯時就會在編譯輸出窗口裏顯示“_
X86 macro activated!”。我們就不會因爲不記得自己定義的一些特定的宏而抓耳撓腮了
。
(2)另一個使用得比較多的pragma參數是code_seg。格式如：
#pragma code_seg( ["section-name"[,"section-class"] ] )
它能夠設置程序中函數代碼存放的代碼段，當我們開發驅動程序的時候就會使用到它。
(3)#pragma once (比較常用）
只要在頭文件的最開始加入這條指令就能夠保證頭文件被編譯一次，這條指令實際上在VC6中就已經有了，但是考慮到兼容性並沒有太多的使用它。
(4)#pragma hdrstop表示預編譯頭文件到此爲止，後面的頭文件不進行預編譯。BCB可以預編譯頭文件以加快鏈接的速度，但如果所有頭文件都進行預編譯又可能佔太多磁盤空間，所以使用這個選項排除一些頭文件。
有時單元之間有依賴關係，比如單元A依賴單元B，所以單元B要先於單元A編譯。你可以用#pragma startup指定編譯優先級，如果使用了#pragma package(smart_init) ，BCB就會根據優先級的大小先後編譯。
(5)#pragma resource "*.dfm"表示把*.dfm文件中的資源加入工程。*.dfm中包括窗體
外觀的定義。
(6)#pragma warning( disable : 4507 34; once : 4385; error : 164 )
等價於：
#pragma warning(disable:4507 34) // 不顯示4507和34號警告信息
#pragma warning(once:4385) // 4385號警告信息僅報告一次
#pragma warning(error:164) // 把164號警告信息作爲一個錯誤。
同時這個pragma warning 也支持如下格式：
#pragma warning( push [ ,n ] )
#pragma warning( pop )
這裏n代表一個警告等級(1---4)。
#pragma warning( push )保存所有警告信息的現有的警告狀態。
#pragma warning( push, n)保存所有警告信息的現有的警告狀態，並且把全局警告
等級設定爲n。
#pragma warning( pop )向棧中彈出最後一個警告信息，在入棧和出棧之間所作的
一切改動取消。例如：
#pragma warning( push )
#pragma warning( disable : 4705 )
#pragma warning( disable : 4706 )
#pragma warning( disable : 4707 )
//.......
#pragma warning( pop )
在這段代碼的最後，重新保存所有的警告信息(包括4705，4706和4707)。
（7）pragma comment(...)
該指令將一個註釋記錄放入一個對象文件或可執行文件中。
常用的lib關鍵字，可以幫我們連入一個庫文件。
(8)#pragma pack()
我們知道在VC中，對於想結構體Struct這樣的類型，VC採用8字節對齊的方式，如果我們不想使用8字節對齊（在網絡變成中經常需要這樣），我們可以在結構體前面加上
#pragma pack(1)
struct
{
......
}
#pragma pack( )
以下是另一個轉載：
在vc6的時代頭文件一般使用ifndef define endif
在vc7的時代頭文件一般成了pragma once
不知道有沒有人深究其中的意義
爲什麼有這樣的代碼，是爲了頭文件不被重複引用，那樣編譯器抱錯的，這兩種方法都是同樣的目的，有沒有區別呢？
還是舉例來說明，可能有好幾個庫，每個庫內部可能都有public.h這個文件，如果使用
ifndef public_h
define public_h
...
endif
那麼當一個文件同時引用兩個這樣的庫時，後一個庫裏的文件就不被編譯了，而pragma once可以保證文件只被編譯一次
看起來pragma once比ifndef define endif要好，那麼ifndef define endif
的地方都pragma once好了。今天碰到了又一個例子，比如你有一個zlib.h在幾個庫都用到，而爲了方便，把zlib每個目錄下copy了一分，因爲這個文件不會作修改，已經很完整了，這個時候如果使用pragma once，就會重複定義，看來ifndef define endif還是又派上用場的地方。
所以對於公有或者接口的文件，使用ifndef define endif，對於內部的文件使用pragma once.
#pragma once 與 #ifndef #define #endif 的區別
對於#pragma once,根據MSDN解說，能夠防止一個文件被多次包含。與#ifndef #define #endif形式的文件保護相比，前者是平臺相關的，可移植性比較差，但是它效率更高，因爲它不需要去打開包含的文件，就可以判斷這個文件有沒有被包含。當然這個工作是系統幫我們完成的。
後者的優點在於它是語言相關的特性，所以可移植性好。但是在包含一個文件的時候，只有打開這個文件，根據文件的保護宏是否已經被定義來判斷此文件是否已經被包含過。效率相對較低。當然在＃i nclude的時候，程序員也可以自己判斷所要包含的文件的保護宏是否已經被定義，來決定是否要包含這個文件。類似下面的代碼：
#ifndef FILE_H_
＃i nclude "file.h"
#endif
這樣作可以得到較高的效率，而且保證可移植性。但是文件之間的依賴性較高，如果一個文件的保護宏改變的話，所有使用如上形式包含這個文件的文件都要修改。有悖於模塊化的思想。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/roger_it/archive/2007/02/09/1506249.aspx
---------------------
作者：hkx1n
來源：CSDN
原文：https://blog.csdn.net/hkx1n/article/details/4313357
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！