2012-02-22 85 views
2

在我的團隊中,我們創建程序集以附加到在我公司其他地方創建和發佈的可擴展軟件。這些程序集通常針對單個客戶端,但有些被重用。我想在這個環境中引入一些標準 - 版本號和安裝程序。實現開發過程 - 版本控制和安裝程序

目前,許多程序集沒有適當的版本控制就轉到客戶端。我想建立自動版本號更新,所以當客戶有問題時,我們可以確定他們的軟件使用了哪些源代碼。

當前,組件由個人將其手動複製到正確的路徑並執行任何必要的註冊來安裝。我想強制人們使用安裝程序包,以便自動處理路徑和註冊。

我可以讓人們使用實施第一步:

[assembly: AssemblyVersion("1.0.*")] 

但我更願意更新的AssemblyFileVersion而非的AssemblyVersion。這是因爲我明白,推進AssemblyVersion與我們的手動安裝相結合可能會導致註冊多個版本的程序集。 AssemblyFileVersion不會自動更新,我對需要開發者安裝第三方工具的解決方案保持警惕。如果我們有正確的安裝過程,問題會有多個版本會消失。

對於第二步,如果我使用Visual Studio安裝項目,則添加程序集會導致它嘗試從原始發佈的軟件中添加其他程序集,這是我不想要的。我想我可以以某種方式將其作爲補丁創建,但我還沒有完成。當然,安裝程序需要可靠的版本號,否則事情會變得很糟糕。

看起來很清楚,我已經寫了這個,我需要同時推進這兩個問題,但我真的寧願一次處理一個問題。

任何想法來解決這兩個問題的最佳途徑?

回答

3

我沒有足夠的信息來指出您的解決方案。你用什麼來構建應用程序和安裝程序?桌面F5構建?團隊基礎服務器?巡航控制?

事情來實現:

1)的Visual Studio部署項目。是的,我會堅持這個評論。在你的情況下,你有依賴掃描問題是不可修復的。即使你右鍵點擊|排除它可以在構建時掃描新依賴項的依賴項。我們甚至編寫了Visual Studio自動化來打開項目,右鍵單擊|排除一切,然後將其保存在生成​​機器上以避免此問題。相信我,這是一條可怕的道路。即使微軟知道它很糟糕,這就是爲什麼它不會在Visual Studio的下一個版本中出現。使用其他工具,例如Windows Installer XML或InstallShield Limited Edition或Professional。

2)您必須更新AssemblyFileVersion。這是變更管理的核心/基礎租戶,它對於使Windows Installer升級和補丁發揮作用至關重要。 AssemblyVersion可以根據自己的決定進行更改,僅適用於強命名和IoC場景,如Prism,您可以在其中撰寫關於構成有效注射類的規則。

3)1.0。*不是你想要的。您需要一個可以增加版本並將其傳遞到構建自動化的系統。你使用什麼取決於你用於構建自動化的東西。我使用Team Foundation Server和CodePlex中的項目來完成我的版本。

4)你不應該在開發者機器上構建。你應該總是使用自動化腳本而不是F5的乾淨構建機器。

+0

目前我們使用F5在桌面上構建。我甚至沒有想過構建機器,因爲我試圖優先考慮最重要的步驟。如果我可以通過構建應用程序一次性解決所有問題,但...我需要做一些研究 - 謝謝。 – TomDestry 2012-02-23 14:13:26

+0

你對源代碼控制使用什麼? – 2012-02-23 14:22:07

+0

Perforce。 (隨機多餘字符!) – TomDestry 2012-02-24 01:41:38

2

如果這些是已發佈的應用程序,那麼安裝程序方法沒問題。如果你通過這種方法添加庫,而不一定是實際的應用程序,那麼像NuGet(包管理器)是一種選擇。 NuGet本身有點幼稚,需要長大一點,但我認爲它應該適合你的基本情況。

如果您已發佈軟件,則客戶端上的一個引導程序需要更新並運行更新安裝程序,這是一種很好的模式。

基本的答案是你有選擇,取決於你正在使用什麼位,並應利用適合你的需求。

相關問題