在小弟第一份工作時,主管就嚴禁無法compile的code不準commit到svn,所以我的習慣也是如此被養成,但換公司後看到的往往都不是如此(好的主管帶你上天堂,不好的主管….嗯…),今天又再度遇到一樣的問題…所以來介紹一下比較正確的reference方法。
通常Reference有三種來源,
1. .Net組件
2. 有Source的類別庫, 可能是公司內部開發 或 網路上找到的OpenSource Library
3. 沒有Source的類別庫 (*.dll)
第一類的通常都沒有問題, 其他兩類的問題是比較常見的問題。其問題大多是參考了一個自己電腦內某個位置的dll, 這個檔案坐在你旁邊的工程師幾乎不太可能跟你放在一樣的路徑…除非你們默契有這麼好…,如下圖(用文字編輯器打開.csproj)我參考了一個在“..\..\..\..\..\Desktop\NLog\Library\NLog.dll “ 的dll, 我旁邊的Partner不會跟我一樣在相同的相對路徑下有這樣的一個檔案存在他的電腦裡, 所以當我把程式給他後,他的電腦是無法編譯的。(注意: *.csproj內所記錄的是相對路徑)
如果類別庫的project(專案)與我們主要專案是同時存在一個solution(方案)內的,我的習慣是reference到project即可, commit到svn也是將整個資料夾連同.sln檔一起commit,未來其他人使用時才不會有問題。
Calculator為類別庫專案, MySample為Console程式專案, 存在同一個ReferenceSample方案內。
Reference by project
如果類別庫的project(專案)與我們主要專案不是同一個solution內那就當作第三類處理。我的習慣是在主要專案下建立一個Library資料夾,並將需要參考的dll放在此資料夾內,加入參考時,透過Browse瀏覽本機內的該專案下的Library資料夾內之*.dll,並將其加入參考,source commit到svn連同此library資料夾一並commit,未來其他人使用時也不會有問題。
以上是很基礎但卻又非常重要的知識,身邊見過不計其數的程式無法正常編譯大部份都是犯了這個錯。另外,把*.csproj, *.sln用文字編輯器打開看看吧,弄懂它記錄了什麼。下回再來介紹吧。
沒有留言:
張貼留言