1.nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc
nafxcw.lib(apphelp.obj) : error LNK2001: unresolved external symbol __mbctype
nafxcw.lib(filelist.obj) : error LNK2001: unresolved external symbol __mbctype
nafxcw.lib(dcprev.obj) : error LNK2001: unresolved external symbol __mbctype
nafxcw.lib(timecore.obj) : error LNK2001: unresolved external symbol __mbctype

..\..\Output\Release/FirewallMan.exe : fatal error LNK1120: 3 unresolved externals

Error executing link.exe.
解決辦法：
PROJECT->SETING->C/C++->PREPROCESSOR->定義 _AFXDLL,完畢。
2.LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library
解決辦法：
PROJECT->SETING->LINK->INPUT->IGNORE LIB...->MSVCRT.LIB

3. 如果它提示：fatal error C1189: #error : Please use the /MD switch for _AFXDLL builds

就這樣改：

C/C++->Code Generation->Multithread DLL

“Linking...
     nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex
     nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
     libcd.lib(crt0.obj) : error LNK2001: unresolved external symbol _main”

1. 解決error LNK2005: ___crtExitProcess 已經(jīng)在 LIBCMTD.lib(crt0dat.obj) 中定義

有的時(shí)候, 在 Debug 模式下編譯沒問題, 換到 Release 模式就發(fā)生一堆問題.

典型的例子, 就是因?yàn)?c++ runtime library 設(shè)定不同, 所造成的重複定義連結(jié)錯(cuò)誤.
而另一個(gè)常見的例子是 專案與 library 使用不同的字元集合設(shè)定
(如: 一個(gè)用 Unicode Character Set, 另一個(gè)用 Multi-Byte Character Set)

這個(gè)錯(cuò)誤
發(fā)生原因, 有可能是
1. 你 link 的 lib 使用 C++ Multi-threaded DLL (/MD)
2. 而你的 source 使用的 C++ runtime library 是 Multi-threaded (/MT)
導(dǎo)致重複定義

解決方法:
兩個(gè)使用相同的 C++ runtime library.
例如都使用 static 的 Multi-threaded (/MT).

2. 錯(cuò)誤 1 error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) 已經(jīng)在 LIBCMT.lib(typinfo.obj) 中定義 MSVCRTD.lib

項(xiàng)目 -> 屬性 -> c/C++  -> 代碼生成  -> 運(yùn)行時(shí)庫  設(shè)置為: 多線程調(diào)試 DLL (/MDd) 
被引用的庫和調(diào)用的程序編譯選項(xiàng)不同，需要改成一致后編譯

3. #pragma once與 #ifndef的區(qū)別
為了避免同一個(gè)文件被include多次
1   #ifndef方式
2   #pragma once方式
在能夠支持這兩種方式的編譯器上，二者并沒有太大的區(qū)別，但是兩者仍然還是有一些細(xì)微的區(qū)別。
    方式一：
    #ifndef __SOMEFILE_H__
    #define __SOMEFILE_H__
    ... ... // 一些聲明語句
    #endif

    方式二：
    #pragma once
    ... ... // 一些聲明語句
    #ifndef的方式依賴于宏名字不能沖突，這不光可以保證同一個(gè)文件不會(huì)被包含多次，也能保證內(nèi)容完全相同的兩個(gè)文件不會(huì)被不小心同時(shí)包含。當(dāng)然，缺點(diǎn)就是如果不同頭文件的宏名不小心“撞車”，可能就會(huì)導(dǎo)致頭文件明明存在，編譯器卻硬說找不到聲明的狀況
    #pragma once則由編譯器提供保證：同一個(gè)文件不會(huì)被包含多次。注意這里所說的“同一個(gè)文件”是指物理上的一個(gè)文件，而不是指內(nèi)容相同的兩個(gè)文件。帶來的好處是，你不必再費(fèi)勁想個(gè)宏名了，當(dāng)然也就不會(huì)出現(xiàn)宏名碰撞引發(fā)的奇怪問題。對應(yīng)的缺點(diǎn)就是如果某個(gè)頭文件有多份拷貝，本方法不能保證他們不被重復(fù)包含。當(dāng)然，相比宏名碰撞引發(fā)的“找不到聲明”的問題，重復(fù)包含更容易被發(fā)現(xiàn)并修正。
   方式一由語言支持所以移植性好，方式二 可以避免名字沖突

4. error LNK2019: 無法解析的外部符號(hào) __imp__PathCombineW
PathCombine是Shell api需要引入庫
#pragma comment( lib, "shlwapi.lib")

5.  error C2662: "MyClass::GetName()”: 不能將“this”指針從“const MyClass”轉(zhuǎn)換為“MyClass &” 
bool MyClass::operator==(const MyClass* n1) const
{
 return GetName() == n1->GetName();
}
原因是不能在const函數(shù)中調(diào)用對象的非const方法，MyClass中的GetName()必須是const的。

6. template 模板
搞死了

模板聲明和定義必須在同一個(gè)文件中，而且只有實(shí)例話模板類型時(shí)才編譯模板實(shí)例

7. error C2275: “MyClass”: 將此類型用作表達(dá)式非法 MyClass.Instance();
 原因：Instance是靜態(tài)方法，用.引用會(huì)出錯(cuò)。應(yīng)該是MyClass::Instance()

8. error LNK2019: 無法解析的外部符號(hào) "public: __thiscall MyClass(void)
原因：只聲明了構(gòu)造函數(shù)，MyClass(); ，但未定義。 可以定義空函數(shù)，或者直接注釋掉，使用默認(rèn)構(gòu)造函數(shù)。

9.  error C2504: “testing”: 未定義基類 
class PackToolTest : testing.Test {}
原因：Test是testing命名空間下的一個(gè)類，需要用域操作符，testing::Test
還有一個(gè)問題，缺少基類繼承權(quán)限（public、protected、private）

10. error C2864: “MyClass::_nullpack”: 只有靜態(tài)常量整型數(shù)據(jù)成員才可以在類中初始化  
class MyClass {

      string _nullpack = "test";

}

原因：c++ 中，成員變量不能在聲明時(shí)初始化，而是在構(gòu)造函數(shù)初始化列表中先初始化

11. error LNK2019: 無法解析的外部符號(hào) _WinMain@16 int main()
原因：由于創(chuàng)建的是Win32 Project，和Win32 console Project的鏈接庫不同
方法1：在程序最開始的地方加上以下語句
#pragma   comment(linker,   "/subsystem:console ")
方法2：project   > >   setting   > >   在link   的project   options   中將/subsystem:windows（console）刪了 

12.類似“已經(jīng)在 msvcprtd.lib(MSVCP80D.dll) 中定義”問題
vs2005 Debug /Release需要分別配制

分析一下錯(cuò)誤來源，會(huì)發(fā)現(xiàn)：
1.     錯(cuò)誤來源主要是重復(fù)定義的問題，而且重復(fù)定義的基本上都是VC Runtime和Standard C++ Library中的函數(shù)
2.     LIBCMT和LIBCPMT為Release下的Lib，本來不應(yīng)該出現(xiàn)在Debug版本的鏈接的Lib中
3.     重復(fù)定義的問題主要出現(xiàn)在：LIBCMT, LIBCPMT, MSVCPRTD, MSVCRTD
來看看出問題的LIB是那些：
1.     LIBCMT：C Runtime庫的多線程靜態(tài)鏈接的Release版本
2.     LIBCPMT：C++ Standard Library的多線程靜態(tài)鏈接的Release版本
3.     MSVCPRTD：C++ Standard Library的多線程DLL的Debug版本
4.     MSVCRTD：C Runtime Library的多線程DLL的Debug版本
當(dāng) 前我們的配置是多線程DLL的Debug版，因此3和4是應(yīng)該出現(xiàn)在link的列表中的，不屬于多余。而后兩者則是只是當(dāng)多線程靜態(tài)鏈接Release版 中才會(huì)出現(xiàn)。這提示我在項(xiàng)目中加入的ANTLR.LIB可能是造成這個(gè)問題的根源，因?yàn)殪o態(tài)庫的編譯選項(xiàng)很容易和主程序發(fā)生沖突，并且根據(jù)實(shí)際信息我們可 以看出ANTLR.LIB應(yīng)該是用多線程靜態(tài)鏈接的Release版本來編譯的。
解決方法：
   1、首先查看編譯項(xiàng)目依賴的其他項(xiàng)目的運(yùn)行時(shí)庫是否一致
   2、如果不一致，改為同樣的運(yùn)行時(shí)庫，如在下編譯的是：“多線程調(diào)試 DLL (/MDd)”,現(xiàn)在需要把所有的依賴項(xiàng)目的運(yùn)行時(shí)庫都改為一致的庫，就ＯＫ了。

13.  error C2143: 語法錯(cuò)誤 : 缺少“;”(在“*”的前面)
原因：產(chǎn)生錯(cuò)誤處，某類型未include，可能頭文件名拼寫錯(cuò)誤、頭文件名已更改

14. error C2572: “MyClass::Invoke”: 重定義默認(rèn)參數(shù) : 參數(shù) 2 
string MyClass::Invoke(const CParam& paraObj, INVOKETYPE type = ASYN)
原因：默認(rèn)參數(shù)，只需在聲明時(shí)指定。方法定義的時(shí)候無需指定默認(rèn)參數(shù)。
string MyClass::Invoke(const CParam& paraObj, INVOKETYPE type /*= ASYN*/)

{ ... }

15. 錯(cuò)誤 C2558 沒有可用的復(fù)制構(gòu)造函數(shù)或復(fù)制構(gòu)造函數(shù)聲明為“explicit”
試圖復(fù)制其復(fù)制構(gòu)造函數(shù)為 private 的類。在大多數(shù)情況下，不應(yīng)復(fù)制具有 private 復(fù)制構(gòu)造函數(shù)的類。通用編程技術(shù)聲明 private 復(fù)制構(gòu)造函數(shù)以防止直接使用類。該類本身可能無用，或需要另一個(gè)類才能正常工作。

嘗試復(fù)制其復(fù)制構(gòu)造函數(shù)為 explicit 的類。用 explicit 聲明復(fù)制構(gòu)造函數(shù)會(huì)阻止將類的對象傳遞到函數(shù)或從函數(shù)返回類的對象。

原因： 拷貝構(gòu)造函數(shù)、賦值函數(shù)參數(shù)必須用const修飾

16. 不能創(chuàng)建抽象類對象
原因： 1. 存在虛函數(shù)未實(shí)現(xiàn)； 2. 由于疏忽重載虛函數(shù)格式錯(cuò)誤(此問題需要仔細(xì)檢查才能發(fā)現(xiàn))； 3. 虛函數(shù)名稱與系統(tǒng)中已有的虛函數(shù)重名，導(dǎo)致重載失?。ㄟ@點(diǎn)很納悶）。

17. 沒有找到MSCRV80D.dll

工程屬性： 配置類型 由 exe 改成 lib 后生成， 然后再改回來
運(yùn)行時(shí)會(huì)出現(xiàn) “沒有找到MSCRV80D.dll” 的異常

解決方法：
工程屬性：MFC的使用 由 “使用標(biāo)準(zhǔn)Windows庫” 改成 “在靜態(tài)庫中使用MFC“ 生成 ，然后再改回來
生成、運(yùn)行 OK

18. CVTRES : fatal error CVT1100: 重復(fù)的資源。type:MANIFEST, name:1, language:0x0409
另一個(gè)則提示為：
LINK : fatal error LNK1123: 轉(zhuǎn)換到 COFF 期間失敗: 文件無效或損壞
已經(jīng)到了鏈接期，應(yīng)該說，問題就不像編譯通不過那么別扭了，而查閱MSDN關(guān)于這兩個(gè)問題的說明，終于找到了解決的方法，現(xiàn)簡單的陳述如下：
首先，出現(xiàn)這兩個(gè)問題的原因都是一個(gè)，即文件中的現(xiàn)有資源文件和新資源字符串表 ID 沖突。微軟也給出了解決這個(gè)問題的方法，但是，在現(xiàn)有的情況下，這個(gè)方法是靠不住的，因?yàn)?，不可能不使用wx.rc資源。所以，一個(gè)變通的解決方法就是：
工程屬性->配置屬性-> 清單工具->輸入和輸出->嵌入清單，選擇[否]，即可。