我最近版本化了我的產品（exe），並且每次在assemblyinfo.cs中增加內部版本號。.net：DLL與EXE的版本號？
工程很好，我的產品目前在版本1.5.x.x，所以每增加4位數字，每次我有一個成功的構建。
現在我有我的DLL也是我的應用程序的一部分。
什麼人會建議如何版本？我是否應該將這些版本與我的exe版本，即1.5.x.x版本相同，還是應該創建另一個不同的版本號？
這是我目前有點困惑。
當我的產品功能增加時，我可以將1.5提高到2.0，但是這會使我的dll在哪裏？
的版本任何建議，將衷心感謝
感謝
您可能會收到很多意見，但我會說保持簡單並且EXE和DLL版本保持同步。如果你真的打算獨立發佈DLL和EXE的版本，我可能會改變我的看法，但是你沒有提到這是必需的。如果您正在處理一些文件，如第三方組件（與主要產品的時間安排不同），那麼您會採用這種方法。但是，再次，如果你沒有這個要求，我會說只是保持所有文件版本同步。
我見過的慣例是使用前3個數字來表示產品版本（主要/次要等），而版本號的第4部分代表源代碼控制版本（因此您確切知道哪個源文件二進制來自）。
希望幫助，
約翰
在我看來，你應該只有一個集信息是整個應用程序共享文件。這樣很容易維護它。當然，這意味着你有一個單一版本的所有組件，這對我來說是可以接受的規範。請參閱this。
在我看來，你必須要管理自己的版本分開。
因爲2個應用程序（EXE）可以使用相同的DLL。 DLL的版本是什麼？
DLL的版本應該獨立於運行它的EXE。
從另一面看 - 爲什麼你需要版本號？例如，一個答案可以是知道在某些客戶位置部署什麼。
因此，如果您的應用程序被部署爲主要的exe文件和一些dll，並且這個dll不是任何其他應用程序的一部分，即使您完全忘記了dll版本控制，也可以感到安全。否則，如果dll將成爲多個項目的一部分，請將它們的版本增加到您認爲合乎邏輯的任何方案，例如，在添加某些功能或增加某些功能時增加MINOR 1.X.0.0，增加MAJOR如果你有完全不同的課程，...
至於增加的，因爲功能的專業，那當然是再次個人口味，我會建議有這樣的：如果添加的功能
你已經觸及了一個非常大的話題，這確實可以得到複雜，因爲你將允許它。
最終，您選擇的版本控制方法將取決於您需要實現的內容以及您需要分配多少時間來維護它。這兩者直接相關。
版本控制的兩個主要目標是並行執行和跟蹤。並行（SxS）允許同一個DLL的多個版本在相同的應用程序中執行。如果不改變彙編版本號，這是不可能的。 跟蹤只是能夠確定客戶機器上運行的確切代碼快照。 兩者都可以通過改變彙編版本來實現，但是第一個可以通過改變彙編版本來實現只有。
許多人會推薦您在所有DLL/EXE中共享版本號 - 這是一個很好的方法，因爲它是最簡單的方法，它也實現了最小的部署靈活性。例如，如果您使用任何形式的合同抽象（通過接口而不是具體類型定義DLL之間的依賴關係），則可以將應用程序劃分爲多個「版本控制筒倉」。 一個例子是客戶端和服務器，在第三個程序集中定義的相互依存關係，您的WCF合同。 如果它們都是單獨版本，那麼你可以釋放一個新版本的服務器（只要它符合同一個合同），而不影響客戶端。反之亦然。正如你所看到的，隨着需求的增長，你將增加你的版本粒度，但它會遭到偷聽。
您可以做的最好的事情就是您正在做的事，坐下來計劃您的需求，然後繪製出您的版本邊界（哪些組件可以通過合同分開）。
接下來的事情取決於測試部門的大小，但我也建議您考慮讓文件版本反映（至少部分）內部版本號/日期。 對於每個客戶發佈版本，您只會增加一次程序集版本，但對於每個來自版本的DLL集合，您應該擁有不同的文件版本。這是因爲當你測試時，並且你找到一個問題時，讓這些DLL唯一標識將消除對DLL源自哪個構建的任何懷疑。
簡單的答案是在您進行更改時增加版本號。不要讓EXE和DLL保持同步，因爲它們沒有理由。該DLL旨在便攜 - 任何EXE理論上都可以使用它。如果您已經擁有該DLL的版本號，則將其用作當前的基準，並在修改它時根據需要增加版本號。
這取決於DLL是否是應用程序的一個組成部分，或者依賴於它們自己的項目。我目前正在研究具有可用於其他項目的庫DLL的應用程序。庫DLL有它自己的彙編信息，我們不保證其版本號將與其使用的每個其他項目的版本號相匹配。 –
@羅伯特哈維，是的 - 當然。如果dll不是應用程序的組成部分，那麼您不能使用共享的assemblyinfo。但在這個特定的問題，似乎該DLL是應用程序的一部分。 – Illuminati