自己遇到了這個(gè)問題,VC2005編的非托管程序也無法在其他電腦XP上運(yùn)行,后來從
C:\Program Files\Microsoft Visual Studio 8\VC\redi
st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT 下找到了下列文件：
msvcm80d.dll
msvcp80d.dll
msvcr80d.dll
Microsoft.VC80.DebugCRT.manifest
復(fù)制了后三個(gè)到游戲目錄就成了:)
轉(zhuǎn)貼:http://www.busfly.cn/post/5.html
VC.net2005寫的程序如何在沒有.Net FrameWork的機(jī)器上運(yùn)行 －－解決"由于應(yīng)用程序的配置不正確，應(yīng)用程序未能啟動(dòng)，重新安裝應(yīng)用程序可能會(huì)糾正這個(gè)問題"
最近在公司的主要工作是做一個(gè)桌面程序,提供給公司正在為移動(dòng)做的項(xiàng)目使用.我開始時(shí)是用C#寫的程序,后來,公司要求,不安裝.net framwork 2.0, 要求我改成C++的.所以后來改成VC2005和程序.原來以為可以不用安裝,附帶幾個(gè)DLL庫就可以運(yùn)行程序了,哪知道,開始時(shí),在別的電腦上都不能運(yùn)行,一運(yùn)行就報(bào)錯(cuò),在XP如的錯(cuò)誤如下圖:
在2000上也會(huì)報(bào)錯(cuò),不過,他會(huì)提示:因?yàn)樯倭薠XX DLL,程序無法啟動(dòng),于是我找到所以提示缺少的DLL放到程序目錄下,2000下就可以運(yùn)行了.可是在XP上還是不行,還是會(huì)報(bào)上面那個(gè)錯(cuò)誤,我猜肯定是少了哪個(gè)DLL,可是找不出來,同事們也用了好多方法幫我找程序用到的DLL,也用到了不少的好工具,也找出了好多DLL,這些DLL加到一起,有10幾M那么多(如下圖).可是XP下還是不行.看來找DLL是沒辦法了.到網(wǎng)上找找辦法吧.
到百度里輸入"由于應(yīng)用程序的配置不正確",搜索一下,嘿嘿,還真不少,都是和我一樣,VC2005寫的程序,在2000下可以用,在XP,2003下不行,不過發(fā)現(xiàn),都是有人問,沒人回答,可憐的人啊,咋就和我一樣不幸呢.繼續(xù)找啊找啊,找到了,找到一個(gè)人,提供了三個(gè)方法,摘下來,如下:
最近在VS2005下用C++寫了一個(gè)Console程序，在一臺(tái)未安裝VS2005上運(yùn)行，顯示：
"系統(tǒng)無法執(zhí)行指定的程序"
原來用VC6和VS2003的話，是會(huì)提示缺少"**.dll"，但是用VS2005卻沒有這樣的提示。
用命令行方式運(yùn)行，提示：
"系統(tǒng)無法執(zhí)行指定的程序"
直接雙擊運(yùn)行，提示：
"由于應(yīng)用程序的配置不正確，應(yīng)用程序未能啟動(dòng)，重新安裝應(yīng)用程序可能會(huì)糾正這個(gè)問題"
自己實(shí)驗(yàn)了一下，感覺以下兩種解決辦法是比較方便的：
方法一：
在C:\Program Files\Microsoft Visual Studio 8\VC\redi
st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT 下找到了下列文件：
msvcm80d.dll
msvcp80d.dll
msvcr80d.dll
Microsoft.VC80.DebugCRT.manifest
把這幾個(gè)文件拷貝到目標(biāo)機(jī)器上，與運(yùn)行程序同一文件夾或放到system32下，就可以運(yùn)行那個(gè)程序了。
其他release版,MFC程序什么的都是拷redist下相應(yīng)文件夾下的文件就可以了,文件夾后都有標(biāo)識(shí)!
方法二：
修改編譯選項(xiàng)，將/MD或/MDd 改為 /MT或/MTd，這樣就實(shí)現(xiàn)了對(duì)VC運(yùn)行時(shí)庫的靜態(tài)鏈接，在運(yùn)行時(shí)就不再需要VC的dll了。
方法三:
工程－》屬性－》配置屬性－》常規(guī)－》MFC的使用，選擇"在靜態(tài)庫中使用mfc"
這樣生成的exe文件應(yīng)該就可以在其他機(jī)器上跑了。
方法四:
你的vc8安裝盤上找到再分發(fā)包vcredist_xxx.exe和你的程序捆綁安裝
我逐一測(cè)試下來,直到第三個(gè)方法才成功.第二個(gè)方法不知道在哪里修改編譯選項(xiàng)所以放棄了,第四個(gè)方法不喜歡,這跟直接安裝.net framework 2.0 有什么區(qū)別嗎?還不如直接安裝.net framework 2.0 呢.
使用第三種方法,編譯后,程序的文件會(huì)變大好多,因?yàn)槠湟呀?jīng)將使用到的DLL庫靜態(tài)編譯到了程序里了.我這個(gè)程序原來的大小是288K,如圖:
而采用第三種方法生成的程序卻有2.85M那么大,如下圖所示:
不過比起那么多的DLL來,這點(diǎn)大小不算什么.不過,在運(yùn)行時(shí),相信占用的內(nèi)存應(yīng)該會(huì)多一點(diǎn).
如果你正在使用VC2005,也出現(xiàn)這樣問題的話,就試試上面的方法吧.
在網(wǎng)上看到別人的方法,和我的差不多,也貼上來,以便更多選擇.
最早出現(xiàn)這個(gè)錯(cuò)誤我和許多人認(rèn)為的一樣
認(rèn)為是缺乏DLL庫文件導(dǎo)致.但是在測(cè)試機(jī)復(fù)制了DLL甚至安裝了.net framework 2.0以后
都無法解決問題,最后確認(rèn)不是由缺乏DLL所致
因?yàn)槌绦蚴羌僿in32的應(yīng)用程,非托管代碼,所以也無需.net framework
Visual C++2003/2005默認(rèn)的MFC程序是使用動(dòng)態(tài)MFC庫(Use MFC in a Shared DLL)來鏈接的
而動(dòng)態(tài)MFC庫使用的是Multi-threaded DLL (/MD)
由于XP對(duì)于PE文件格式監(jiān)測(cè)更加嚴(yán)格.
就會(huì)導(dǎo)致部分使用多線程DLL的可執(zhí)行文件在調(diào)用的時(shí)候出錯(cuò)
修改項(xiàng)目屬性的編譯開關(guān)
Project->Property->configuration Properties->C/C++->Code Generation->Runtime Library
修改成Multi-threaded (/MT)
修改了Runtime類型以后
需要將MFC的編譯類型也改成靜態(tài)庫
Project->Property->configuration Properties->General->Use of MFC
修改成Use MFC in a Static Library
一部分情況下在這步就能解決問題
另外一部分情況會(huì)遇見如下情況
編譯器報(bào)錯(cuò)
CODE:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj)
[Copy to clipboard]
產(chǎn)生這個(gè)問題的原因是庫依賴關(guān)系
在Project->Property->configuration Properties->Linker->Command Line
加入編譯開關(guān)/verbose:lib可以顯示詳細(xì)的庫鏈接順序
CODE:
------ Build started: Project: PerfMonDemo, Configuration: Release Win32 ------
Linking...
Searching libraries
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
.................
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Finished searching libraries
.\Release/PerfMonDemo.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://d:\Dev\Performance Monitor\Release\BuildLog.htm"
PerfMonDemo - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
[Copy to clipboard]
我們發(fā)現(xiàn)在libcpmt.lib聲明過的operator new在nafxcw.lib中再次定義
解決方法如下
Project->Property->configuration Properties->Linker->Input->Additional Dependencies
加入
nafxcw.lib
libcpmt.lib
Project->Property->configuration Properties->Linker->Input->Ignore Specific Library
加入
nafxcw.lib
libcpmt.lib
這樣鏈接程序就不會(huì)先按照默認(rèn)順序來連接這兩個(gè)庫文件
而是在最后在加入對(duì)他們的引用.這樣就避免了這個(gè)問題
下面是一張可能發(fā)生沖突的列表
若要使用此運(yùn)行時(shí)庫 請(qǐng)忽略這些庫
單線程 (libc.lib) libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多線程 (libcmt.lib) libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多線程 (msvcrt.lib) libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
調(diào)試單線程 (libcd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
調(diào)試多線程 (libcmtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的調(diào)試多線程 (msvcrtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib