簡(jiǎn)介Caffe 是伯克利視覺(jué)與學(xué)習(xí)中心開(kāi)發(fā)的流行深度學(xué)習(xí)框架caffe-windows 壓縮包面向需要在 Windows 平臺(tái)使用 Caffe 的開(kāi)發(fā)者省去自行編譯的復(fù)雜過(guò)程降低環(huán)境搭建門(mén)檻。包內(nèi)共有 888 個(gè)文件涵蓋 cpp、hpp、cu 等源碼與頭文件cmake、vcxproj、sln 等工程構(gòu)建配置prototxt 模型定義、Python 訓(xùn)練與轉(zhuǎn)換腳本、Markdown 說(shuō)明文檔和示例圖片等整體約 8.67MB目錄組織清晰便于按模塊查閱也能快速定位需要的源碼、配置或模型文件。已有 292 人學(xué)習(xí)下載。資源圍繞 Windows 下的安裝使用展開(kāi)梳理了 Visual Studio、CMake、CUDA、cuDNN、Python 與 NumPy 等組件的配置要點(diǎn)并給出從源碼獲取、配置修改、編譯構(gòu)建到功能測(cè)試的完整思路可以幫助讀者規(guī)避常見(jiàn)錯(cuò)誤。對(duì)于需要在 Windows 上訓(xùn)練或部署 Caffe 模型的初學(xué)者和研發(fā)人員這份整理好的包體與配套注意點(diǎn)很有參考價(jià)值也能為后續(xù)自定義網(wǎng)絡(luò)結(jié)構(gòu)提供基礎(chǔ)。 Caffe 在 Windows 上一直是個(gè)讓人又愛(ài)又恨的話題。這個(gè)框架本身是伯克利視覺(jué)實(shí)驗(yàn)室的產(chǎn)物當(dāng)年在 CV 領(lǐng)域幾乎是標(biāo)配特別是那些經(jīng)典的 ResNet、VGG、SSD 模型的 prototxt 和 caffemodel到現(xiàn)在還在各種老項(xiàng)目里躺著。但官方源碼壓根不提供 Windows 支持所謂 caffe-windows 全靠社區(qū)分支硬撐。這篇東西就圍繞“怎么在 Windows 上把 Caffe 跑起來(lái)”這個(gè)主題把我踩過(guò)的坑、驗(yàn)證過(guò)的方案、排查思路全部攤開(kāi)來(lái)講適合需要復(fù)現(xiàn)老模型、對(duì)比論文結(jié)果、或者因?yàn)轫?xiàng)目歷史包袱不得不留在 Caffe 生態(tài)里的同學(xué)。我默認(rèn)你的場(chǎng)景是Windows 10/11 系統(tǒng)想用 Caffe 訓(xùn)練或推理一個(gè)已有的深度模型但不想為此專門(mén)裝雙系統(tǒng)或虛擬機(jī)。如果你屬于這種情況這篇內(nèi)容應(yīng)該能幫你省下不少時(shí)間。1. 方案選型不是所有 Caffe-Windows 都長(zhǎng)一個(gè)樣1.1 官方不支持時(shí)我們有哪些路可以走Caffe 官方倉(cāng)庫(kù)的 README 寫(xiě)得很清楚僅支持 Linux 和 macOS。Windows 用戶想用不外乎三條路一是用微軟維護(hù)的 BVLC/caffe 的 Windows 分支二是用 conda 直接裝編譯好的包三是找第三方預(yù)編譯包或自己編譯。三條路各有代價(jià)。微軟那個(gè)分支當(dāng)年確實(shí)是福音能在 Visual Studio 里打開(kāi) Caffe.sln 直接編譯但問(wèn)題也明顯它停更太久綁定的依賴版本停留在 VS2013/2015 時(shí)代。如果你現(xiàn)在的機(jī)器裝的是 VS2022光是改平臺(tái)工具集就能折騰半天。而 conda 裝 caffe 或 caffe-gpu 是最快的路子一條命令搞定但包管理器里的版本比較老而且如果你需要改動(dòng) Caffe 源碼、加自定義層這條路就走不通了。我的建議很直接如果你只是想跑通一個(gè)已有的模型做推理優(yōu)先試 conda如果你要基于 Caffe 改網(wǎng)絡(luò)結(jié)構(gòu)、加自定義 Python 層那就老老實(shí)實(shí)自己編譯。我自己兩種方式都試過(guò)后來(lái)因?yàn)橐?SS 的檢測(cè)頭還是走回了源碼編譯這條路。1.2 分支選擇決定了你的痛苦程度確定要自己編譯后下一個(gè)問(wèn)題就是選哪個(gè)倉(cāng)庫(kù)。在 Windows 上比較常見(jiàn)的兩個(gè)來(lái)源BVLC/caffe 的 Windows 分支官方賬號(hào)下維護(hù)的 windows 分支年代久遠(yuǎn)但相對(duì)穩(wěn)定支持 VS2013/2015。willyd/caffe-windows社區(qū)維護(hù)者 willyd 的分支更新一些對(duì) VS2015/2017 以及新版本 CUDA 兼容性更好。我自己用的是 willyd 這個(gè)分支原因很簡(jiǎn)單它能支持 CUDA 10.0 和 cuDNN 7.x這個(gè)組合在 2018 年以后很長(zhǎng)一段時(shí)間里是 Windows 深度學(xué)習(xí)環(huán)境的主流搭配能找到的資料也最多。如果你機(jī)器顯卡太新比如 RTX 30 系以后那就得注意 CUDA 版本兼容問(wèn)題了這屬于另一個(gè)坑后面會(huì)提到。選分支時(shí)還有一個(gè)判斷技巧去 GitHub 看最近的 commit 時(shí)間和 Issues 內(nèi)容。如果最近一兩年都沒(méi)人維護(hù)說(shuō)明用的人少、踩坑資料也少出問(wèn)題基本只能自己啃源碼。2. 編譯前環(huán)境準(zhǔn)備這幾項(xiàng)不做好會(huì)浪費(fèi)一整天2.1 Visual Studio、CUDA、cuDNN 版本怎么搭配先說(shuō)結(jié)論這是我在多臺(tái)機(jī)器上驗(yàn)證過(guò)最省心的一套組合組件推薦版本備注Visual Studio2015 或 2017不要直接用 VS2022 嘗試?yán)戏种UDA10.0 或 9.2驅(qū)動(dòng)升級(jí)不影響工具包版本要匹配cuDNN7.4 或 7.6要和 CUDA 一一對(duì)應(yīng)Python3.5 或 3.6編譯 pycaffe 接口時(shí)建議使用OpenCV3.4.x盡量不要用 4.x接口變了選這套組合的原因很實(shí)際Caffe 的 Windows 分支源碼依賴較老新編譯器對(duì)老代碼的強(qiáng)類型檢查會(huì)導(dǎo)致大量“無(wú)法解析的外部符號(hào)”“未知類型名”這類編譯錯(cuò)誤。VS2015 對(duì)老代碼的容忍度最高而 CUDA 10.0 之后的版本從編譯角度看變化不大但 Caffe 源碼里的 caffe.pb.h 是拿 protobuf 生成的protobuf 版本太新會(huì)和源碼里的舊文件沖突。這里有個(gè)細(xì)節(jié)如果你用的是 30 系以后顯卡CUDA 10.0 裝倒是能裝但驅(qū)動(dòng)不認(rèn)舊版工具包的可能性很大編譯出來(lái)跑不起來(lái)。這種情況可以試試 CUDA 11.x 手動(dòng)修源碼兼容但工作量會(huì)大不少建議評(píng)估一下是不是直接用 conda 預(yù)編譯包更劃算。2.2 依賴庫(kù)下載別一股腦全裝Caffe 依賴的東西不少OpenCV、protobuf、glog、gflags、lmdb、leveldb、hdf5、boost。Windows 上沒(méi)有 apt-get你得一個(gè)個(gè)下載源碼或二進(jìn)制包。先說(shuō) OpenCV官方源碼下載后你需要把它編譯成 static 庫(kù)。Windows 分支要求 OpenCV 必須是 static build也就是說(shuō)要讓 Caffe 把圖像編解碼能力直接編進(jìn)去而不是運(yùn)行時(shí)找 dll。你的 OpenCV 源碼編譯時(shí)對(duì)著 CMake 配置把 BUILD_SHARED_LIBS 關(guān)掉即可。protobuf 這塊我特別提醒一下Caffe 用的是 protobuf 的 C 運(yùn)行時(shí)來(lái)讀寫(xiě)模型結(jié)構(gòu)文件。如果你裝的是 protobuf 3.6 以上版本編譯 Caffe 時(shí)大概率會(huì)遇到“protobuf 版本不匹配”的報(bào)錯(cuò)因?yàn)?Caffe 源碼里預(yù)生成的 .pb.cc 文件是拿舊版 protobuf 生成的。解決辦法只有一個(gè)就是在 Caffe 的 src/caffe/proto 目錄下重新生成一次 .pb.cc 和 .pb.h這要求你的 protobuf 編譯器版本和運(yùn)行庫(kù)一致。其他依賴用一種比較笨但有效的方式處理直接把庫(kù)文件放到 Caffe 源碼的 dependencies 目錄里然后修改 CommonSettings.props 指定路徑。不用刻意追求目錄清爽能編過(guò)就是勝利。2.3 Python 接口的版本陷阱很多人編譯 Caffe 的 Python 接口時(shí)會(huì)踩這個(gè)坑裝好 Anaconda設(shè)好 PYTHON_INCLUDE、PYTHON_LIB 路徑編譯時(shí)卻報(bào)“無(wú)法打開(kāi) Python.h”。原因通常是 VS 默認(rèn)找的是 64 位 Python而你環(huán)境里裝的是 32 位或者反之。我的建議是給 Python 接口專門(mén)建一個(gè)獨(dú)立的 conda 環(huán)境不要用 base。命令無(wú)非是 conda create -n py36 python3.6然后在 CommonSettings.props 里把 Python 相關(guān)路徑指到這個(gè)環(huán)境。這個(gè)環(huán)境保持干凈除了 numpy 之外什么都別裝避免依賴沖突。3. 編譯實(shí)操?gòu)南螺d源碼到跑通示例3.1 源碼準(zhǔn)備和關(guān)鍵配置項(xiàng)首先把倉(cāng)庫(kù)克隆到本地路徑有個(gè)硬性要求不能有中文不能有空格。我見(jiàn)過(guò)有人把工程放到“C:\Users\張三\我的項(xiàng)目\caffe-windows”結(jié)果是編譯器各種詭異的路徑錯(cuò)誤折騰一晚上才發(fā)現(xiàn)是路徑問(wèn)題。建議直接放到 C:\caffe 這種短路徑下。打開(kāi) windows 目錄下的 CommonSettings.props主要改這幾個(gè)地方!-- CPU_ONLY 設(shè)為 true 時(shí)只編譯 CPU 版本不依賴 CUDA -- CpuOnlyBuildfalse/CpuOnlyBuild !-- 開(kāi)啟 Python 接口 -- PythonSupporttrue/PythonSupport !-- CUDA 目錄按實(shí)際安裝路徑填 -- CudaVersion10.0/CudaVersion PythonDirD:\Anaconda3\envs\py36\/PythonDir另一個(gè)重要配置是 cuDNN 的路徑。把解壓后的 cuDNN 文件夾里的 cuda 目錄內(nèi)容復(fù)制到 CUDA 安裝目錄對(duì)應(yīng)位置然后確認(rèn) CommonSettings.props 里的CuDnnPath指向 CUDA 安裝根目錄。3.2 Visual Studio 編譯流程詳解用 VS2015 打開(kāi) Caffe.sln首先要做的事是檢查解決方案里的項(xiàng)目依賴關(guān)系。默認(rèn)會(huì)包含 libcaffe、caffe、pycaffe 等幾個(gè)項(xiàng)目。右鍵解決方案選擇“配置管理器”確認(rèn)當(dāng)前是 Release x64 模式然后直接生成。第一次編譯耗時(shí)比較長(zhǎng)通常在 20~40 分鐘取決于機(jī)器性能。需要提醒的是編譯過(guò)程中如果報(bào)錯(cuò)不要急著改代碼。很多錯(cuò)誤屬于配置層面的比如找不到 libcaffe.lib其實(shí)是編譯順序不對(duì)caffe.exe 項(xiàng)目依賴的 libcaffe 還沒(méi)有生成。調(diào)整項(xiàng)目依賴關(guān)系或者先單獨(dú)編譯 libcaffe 項(xiàng)目即可。編譯完成后你會(huì)在 x64\Release 目錄下看到 caffe.exe、libcaffe.lib 以及 pycaffe 目錄下的 caffe 包。這時(shí)候可以快速驗(yàn)證一下 C 版本是否可用把該目錄加入系統(tǒng) PATH然后打開(kāi)命令行執(zhí)行 caffe。如果輸出版本信息說(shuō)明編譯成功。3.3 Python 接口安裝和環(huán)境變量配置pycaffe 的安裝方式和普通 Python 包不太一樣。你不需要執(zhí)行 pip install直接把編譯生成的 pycaffe 目錄添加到環(huán)境變量 PYTHONPATH 即可。我的具體做法是在系統(tǒng)環(huán)境變量里新建一個(gè) PYTHONPATH值填 C:\caffe\Build\x64\Release\pycaffe。然后在 Python 里嘗試 import caffe能成功就說(shuō)明接口通了。如果不成功優(yōu)先檢查你是否在同一個(gè) conda 環(huán)境里執(zhí)行以及 numpy 版本是否是 1.16 左右的舊版本——numpy 1.17 以后某些 API 變化會(huì)導(dǎo)致 import 報(bào)錯(cuò)這算是比較常見(jiàn)的坑。4. 常見(jiàn)問(wèn)題排查這些坑幾乎每個(gè)人都會(huì)遇到4.1 命令行運(yùn)行 caffe 時(shí)閃退或提示找不到 dll原因基本只有兩個(gè)依賴的 dll 不在 PATH 里或者 cuda 運(yùn)行時(shí)庫(kù)版本不匹配。前者好辦把 OpenCV 的 dll、CUDA 的 bin 目錄都加進(jìn) PATH 試一遍后者就得用工具查看 exe 到底依賴哪些 cudart64_*.dll再比對(duì)系統(tǒng)里裝的是哪個(gè)版本。排查這類問(wèn)題我推薦用 Dependencies 這個(gè)工具比老舊的 Dependency Walker 更直觀能顯示 dll 依賴樹(shù)和缺少的模塊。順著紅色標(biāo)記找?guī)缀趿⒖潭ㄎ粏?wèn)題。4.2 Check failed: registry.count(type) 1 這個(gè)報(bào)錯(cuò)怎么處理這個(gè)報(bào)錯(cuò)在跑模型時(shí)非常常見(jiàn)意思是 prototxt 網(wǎng)絡(luò)定義文件里寫(xiě)了某個(gè) layer type但 Caffe 里沒(méi)有注冊(cè)這個(gè)層。出現(xiàn)這種情況通常是三類原因一是拼寫(xiě)錯(cuò)誤比如把 Convolution 寫(xiě)成 Convoution二是用了 Caffe 本身沒(méi)有的自定義層比如某些老項(xiàng)目里寫(xiě)的 NormalizeLayer 其實(shí)是某個(gè)特定分支才有的三是這個(gè)層的實(shí)現(xiàn)寫(xiě)在了 Python 層里部署時(shí)沒(méi)有把對(duì)應(yīng)的 Python 模塊路徑加進(jìn)來(lái)。排查思路很直接先把 prototxt 里的 layer type 和源碼 src/caffe/layers 目錄下的文件名對(duì)照一遍。如果發(fā)現(xiàn)確實(shí)只有老版本 Caffe 才有這個(gè)層那只能切換分支或者把該層的實(shí)現(xiàn)手動(dòng)移植過(guò)來(lái)。4.3 編譯報(bào)錯(cuò) MSB8036 找不到 Windows SDK 版本微軟分支的工程文件默認(rèn)指定了某一年份的 SDK而新裝的 VS 不一定帶那個(gè)版本。解法是在工程屬性里把 Windows SDK 版本改成你機(jī)器上實(shí)際安裝的版本。操作路徑右鍵項(xiàng)目 - 屬性 - 配置屬性 - 常規(guī) - Windows SDK 版本下拉選擇最新安裝的那個(gè)。還有一個(gè)比較隱蔽的類似問(wèn)題是平臺(tái)工具集版本不匹配比如工程默認(rèn)是 v140VS2015而你用的是 VS2017 的 v141。這種情況經(jīng)常伴隨一堆莫名其妙的編譯錯(cuò)誤把平臺(tái)工具集改對(duì)就全好了。4.4 老代碼和新編譯器的兼容性問(wèn)題如果你實(shí)在沒(méi)辦法只能用 VS2017 或更高版本編譯老 Caffe 分支會(huì)遇到一類很統(tǒng)一的報(bào)錯(cuò)源碼里某個(gè)頭文件里用了一個(gè)老編譯器允許但新編譯器不認(rèn)的語(yǔ)法。最典型的是 unknown type name uint8_t。這個(gè)報(bào)錯(cuò)本質(zhì)是 Caffe 源碼沒(méi)有主動(dòng)包含標(biāo)準(zhǔn)庫(kù)的 頭文件。工程里 caffe.pb.h 生成時(shí)可能也沒(méi)帶上。解決辦法是全局搜索一下哪個(gè)文件用了 uint8_t 但沒(méi)有 include 需要的頭手動(dòng)補(bǔ)上就行。不要試圖靠更改編譯器級(jí)別規(guī)避治標(biāo)不治本。4.5 模型訓(xùn)練時(shí) loss 一直是 NaN 或輸出全零這個(gè)問(wèn)題和 Windows 本身關(guān)系不大但我在 Windows 平臺(tái)上遇到過(guò)太多次還是提一嘴。如果你用的是自定義數(shù)據(jù)且通過(guò) lmdb 格式輸入大概率是數(shù)據(jù)預(yù)處理環(huán)節(jié)出了問(wèn)題比如圖片均值文件沒(méi)有生成、mean.binaryproto 格式和 prototxt 里的配置不匹配。更隱蔽的是 GPU 模式下的浮點(diǎn)計(jì)算問(wèn)題。某些老分支的 Caffe 在特定 CUDA 版本下BatchNorm 層的實(shí)現(xiàn)會(huì)踩到 cuDNN 的 bug導(dǎo)致訓(xùn)練數(shù)值不穩(wěn)定。這種問(wèn)題排查起來(lái)很難受我的建議是先用 CPU 模式跑幾十個(gè)迭代如果 CPU 正常而 GPU 異常十有八九是 cuDNN 版本匹配問(wèn)題換個(gè)版本重編一次即可。5. 實(shí)操驗(yàn)證跑通一個(gè)真實(shí)的推理任務(wù)5.1 準(zhǔn)備模型文件和測(cè)試圖片編譯成功不等于萬(wàn)事大吉強(qiáng)烈建議跑一個(gè)完整的推理流程做驗(yàn)證。最簡(jiǎn)單的方式是用官方訓(xùn)練好的 CaffeNet 或 ResNet-50 模型。需要準(zhǔn)備三個(gè)文件網(wǎng)絡(luò)定義 prototxt、訓(xùn)練好的 caffemodel、以及一張測(cè)試圖片。模型文件去對(duì)應(yīng)項(xiàng)目官方頁(yè)面下載即可。這里提醒一下有些老模型的 caffemodel 是從 Caffe 的 GitHub 倉(cāng)庫(kù)發(fā)布頁(yè)下載的格式?jīng)]問(wèn)題但對(duì)應(yīng)的 prototxt 可能依賴一個(gè)老版本的 Deploy 頭直接跑可能報(bào) Input layer 相關(guān)錯(cuò)誤。遇到的話把測(cè)試圖片的尺寸、通道數(shù)、均值參數(shù)改對(duì)就行。5.2 用 caffe.exe 命令行和 Python 接口分別驗(yàn)證命令行驗(yàn)證最簡(jiǎn)單執(zhí)行一條類似這樣的命令caffe.exe test -model deploy.prototxt -weights bvlc_reference_caffenet.caffemodel -gpu 0 -iterations 1如果能看到測(cè)試 loss 和 accuracy 輸出說(shuō)明 C 版本鏈路正常。Python 接口驗(yàn)證更靈活核心代碼就幾行import caffe import numpy as np net caffe.Net(deploy.prototxt, bvlc_reference_caffenet.caffemodel, caffe.TEST) transformer caffe.io.Transformer({data: net.blobs[data].data.shape}) transformer.set_transpose(data, (2, 0, 1)) transformer.set_mean(data, np.load(ilsvrc_2012_mean.npy).mean(1).mean(1)) transformer.set_raw_scale(data, 255) net.blobs[data].reshape(1, 3, 227, 227) img caffe.io.load_image(test.jpg) net.blobs[data].data[...] transformer.preprocess(data, img) out net.forward() print(out[prob][0].argmax())這段能跑出指數(shù)結(jié)果說(shuō)明 pycaffe 接口的預(yù)處理、前向推理、模型文件讀取鏈路都正常。很多人編譯成功后跑 Python 報(bào)錯(cuò)多數(shù)都卡在 transformer 的均值和縮放參數(shù)上這一步值得單獨(dú)驗(yàn)證。5.3 把 Windows 上的 Caffe 模型轉(zhuǎn)到其他框架如果你留 Caffe 是為了老模型遷移那有一個(gè)重要步驟導(dǎo)出模型。Caffe 模型轉(zhuǎn)成 ONNX 是常見(jiàn)做法網(wǎng)上工具不少但先在 Windows 本地把 Caffe 跑通是第一步。這就能體現(xiàn)自己編譯的好處了轉(zhuǎn)換工具多半是一段 Python 腳本依賴 pycaffe 接口只有編譯過(guò) pycaffe 的環(huán)境才能運(yùn)行。轉(zhuǎn)換的時(shí)候有個(gè)很常見(jiàn)的坑Caffe 模型的 blob 命名和 ONNX 期望的不一致。比如 Concat 層的 output 參數(shù)Caffe 里默認(rèn)是空ONNX 要求顯示聲明。這類問(wèn)題沒(méi)有通用解法基本上就是按照?qǐng)?bào)錯(cuò)信息一個(gè)個(gè)改 prototxt再重新加載驗(yàn)證。6. 注意事項(xiàng)與最終建議整個(gè) Caffe-Windows 的折騰過(guò)程本質(zhì)上是在跟舊代碼、舊工具鏈、舊依賴做斗爭(zhēng)。有幾條經(jīng)驗(yàn)我覺(jué)得值得單獨(dú)拎出來(lái)強(qiáng)調(diào)一下。第一不要追求新版本。很多人在 Windows 上裝 Caffe 習(xí)慣性地裝最新 CUDA、最新 VS、最新 Python這其實(shí)適得其反。Caffe-Windows 的源碼綁定了一組特定版本你只要換掉其中一個(gè)連鎖反應(yīng)會(huì)接踵而至。整套環(huán)境盡量按老版本配齊越接近當(dāng)時(shí)作者的開(kāi)發(fā)環(huán)境越容易成功。第二備份好編譯產(chǎn)物。編譯一次 Caffe 至少要二三十分鐘如果調(diào)試中某個(gè)環(huán)節(jié)把 libcaffe.lib 弄壞了重新編譯非常浪費(fèi)時(shí)間。我在踩過(guò)一次坑之后每次成功編譯完都會(huì)把整個(gè) x64\Release 目錄壓縮備份一份后續(xù)出了任何問(wèn)題直接解壓恢復(fù)省下的時(shí)間完全值得。第三盡量在 conda 虛擬環(huán)境里操作 Python 相關(guān)的內(nèi)容。之前說(shuō)了pycaffe 對(duì) numpy 版本有要求虛擬環(huán)境隔離后不會(huì)影響你日常用 Python 干活反過(guò)來(lái)日常升級(jí)包也不會(huì)把 pycaffe 弄崩。如果問(wèn)我在實(shí)際項(xiàng)目中怎么評(píng)價(jià) Caffe-Windows 這套方案我的體會(huì)是它確實(shí)老、確實(shí)折騰、確實(shí)有不少歷史遺留問(wèn)題但考慮到大量老模型和學(xué)術(shù)代碼都長(zhǎng)在 Caffe 的生態(tài)里能在 Windows 下多保留一套可用的 Caffe 環(huán)境往往能在關(guān)鍵時(shí)刻解決問(wèn)題。至于后續(xù)的新項(xiàng)目我會(huì)建議盡快轉(zhuǎn)向更現(xiàn)代、跨平臺(tái)支持更好的框架但這就是另一個(gè)話題了。最后再分享一個(gè)小技巧如果你只是偶爾跑一下 Caffe 模型不需要每天開(kāi)發(fā)完全可以把編譯好的整個(gè) Caffe 目錄拷貝到一個(gè)移動(dòng)硬盤(pán)或者網(wǎng)絡(luò)存儲(chǔ)上。這樣換機(jī)器后只需要把 CUDA 運(yùn)行時(shí)庫(kù)、依賴 dll 配好直接就能用不需要每次重新編譯。這個(gè)方法我用了很久相當(dāng)省心。本文還有配套的精品資源點(diǎn)擊獲取