處理程序集版本的正確方法是什麼？

我期待着爲即將到來的項目實施每日構建。處理程序集版本的正確方法是什麼？

但在此之前，我需要知道如何正確地版本程序集。

我有以下的憂慮：

如果每個裝配有一個獨立的版本號或他們都應該共享相同的版本？
我應該使用*版本進行構建和修訂嗎？
是否修訂與日常構建相關？

來源

2009-09-10 Pierre-Alain Vigeant

我們郵票公司產品中的所有組件，使用以下步驟相同的版本號：

連接所有組件含有版本號信息的 AssemblyInfoCommon.cs：看here 爲例。
生成AssemblyInfoCommon.cs文件作爲構建的一部分（在我們的情況下）惡性asminfo任務，巡航控制.NET和SVN修訂貼標機

在我們的例子中，我們不不使用*版本。所有部署的版本都構建在構建服務器上。我們不擔心我們桌面上的版本號。

來源

2009-09-12 12:19:13

+1構建服務器的內部版本號。構建應該是可重複的，這意味着它們應該是腳本化的，並且在桌面上執行它們使得懶惰和「只知道」如何執行它變得容易，而不是經歷創建構建腳本的麻煩。 – gregmac 2011-11-10 00:30:56

所以每件應具有相同的版本，這是通常的發行版的組合，即3.4 +的內部版本號是表示該版本已經編譯生成服務器上的次數的序列。該修訂是相關的，因爲它顯示了您爲該版本創建的構建數量。你可以通過2種方式之一來實現這一點。第一種方法是，如果您計劃發佈3.4版，那麼當您開始使用該版本時，那麼這是您的主要版本號，並且您的次要版本號會隨着版本的增加而增加。另一種方法是嚴格控制構建版本，當你準備好發佈QA /迴歸時，你的主要版本設置爲3.4，而你的次要版本號爲0.你用這種方式嚴格控制事物直到你釋放。這樣您就可以通過次要版本號來控制您的服務包編號。希望這可以幫助。

來源

2009-09-10 00:41:19

答案真的取決於你想用程序集版本號來完成什麼。如果您正在執行ClickOnce部署並希望獨立下載更新的程序集，則需要使每個程序集都獨立版本化 - 否則，我認爲使程序集版本與軟件版本號匹配通常很不錯。在更復雜的情況下，您可能需要另一種策略。

我在以前的公司使用的方案是major.minor.revision.build - 因此在1.0版本的產品中，每個程序集的程序集版本和程序集版本都是1.0.0.1129（例如）。這樣可以很容易地將哪些程序集作爲哪個軟件版本的一部分，直到構建編號。我們使用預編譯搜索完成了這項工作，並在每個AssemblyInfo.cs文件中進行替換，以便用我們的自動構建過程提供的版本號來替換令牌。

來源

2009-09-10 00:42:10

我通常會同意所有程序集應該有相同的版本號;然而，我會對此做出一個警告。如果其中一個程序集在此項目之外的其他地方使用，或者如果它被認爲是它自己的項目，它應該有它自己的版本號。它也可能被移出解決方案並進入它自己的解決方案。我提到這一點的唯一原因是我曾多次看到人們在其他幾個地方使用過一個程序集，但主要集中在一個地方，他們試圖保持版本的正確性。這樣做不是個好主意。我認爲單一職責原則也適用於解決方案/項目級別。

就編號而言，我同意Guy Starbuck（major.minor.revision.build）。這是我一直這樣做的方式，它一直運行良好。

來源

2009-09-14 07:17:01

我們有一個大型應用程序（數百個程序集），頻繁發佈（約1個月）。我們去「爲每個程序集提供相同的版本」，但是它對我來說是一個持續不斷的來源，儘管事實上這些組件的接口很少（如果有的話）改變，但是1版本的程序集完全不兼容。

如果您遇到這種情況，那麼您可能會從版本控制程序集中分別獲益 - 每次更新程序集時，只打算在實際需要中斷程序集綁定的情況下增加版本號（例如，如果界面更改，或者您想防止某人意外使用以前的版本，這些更改是非常重要的）。

來源

2009-09-17 23:07:06 Justin

處理程序集版本的正確方法是什麼？

回答

相關問題