.NETプロジェクトでのバージョン管理だけでなく

私の製品バージョンを長い間変更する方法論では、理解できない瞬間がありました。 製品に変更を加えるときにバージョンを変更する方法が多すぎます。 私が出くわした戦略は、バージョン番号に4つの番号(たとえば、1.5.2.871)を使用しています。



最初の3つは常に手動で変更され、通常10を超えず、最後の3つは手動または自動で変更され、ビルド番号を意味します。 Visual Studioソリューションと製品構造に1つの実行可能プロジェクトではなく、さまざまなタイプ(実行可能モジュールとライブラリ)の複数のプロジェクト(10以上)が含まれている場合、製品コンポーネントにバージョン番号を割り当てる方法は特にわかりにくいものでした。



私にとっては、興味があれば、私にぴったりのソリューションを思いつきました。



特に、.NETプロジェクトでは、デフォルトでAssemblyInfo.csファイルが作成されます。デフォルトでは、次のコードが存在します。



 //アセンブリのバージョン情報は、次の4つの値で構成されます。
 //
 //メジャーバージョン
 //マイナーバージョン 
 //ビルド番号
 //改訂
 //
 //すべての値を指定するか、ビルド番号とリビジョン番号をデフォルトにすることができます 
 //以下に示すように「*」を使用して:
 // [アセンブリ:AssemblyVersion( "1.0。*")]
 [アセンブリ:AssemblyVersion( "1.0.0.0")]
 [アセンブリ:AssemblyFileVersion( "1.0.0.0")]




最後まで理解できなかったのかもしれませんが、AssemblyVersion( "1.0。*")を使用してメカニズムを取得することはできませんでした。 また、MSDNで明確な説明が見つかりませんでした。 したがって、私は独自のソリューションについて考えることにしました。これは現在、Subversionでうまく機能しています。



製品バージョンをリリースする場合、多くの場合、バージョンの最初の3桁を手動で変更する必要があります。 1桁目(メジャー)を増やします。非常に重要な変更であり、カーネルが書き直されているか、その一部である可能性があります。 2桁目(マイナー)-新しい機能が追加され、比較的小さい可能性があります。 3桁目-修正されたバグに加え、マイナーな改善、機能の追加。 しかし、ビルドをテストおよび識別するためには、テスターで作業するときにはこれだけでは不十分です。 ディストリビューションに常に「MyProductSetup_1.3.7」という名前を付けてテスト用に送信し、問題追跡ツールを使用して、問題が発生したビルドを特定するのは非常に困難です。 つまり、バージョン番号の最後の数字をインクリメントする必要があります。 新しいアセンブリごとにソリューションに多くのプロジェクトがあるときにこれを手動で行うことは、非常に退屈な仕事です。



したがって、自動バージョンインクリメントを伴う自動アセンブリを使用することにしました。 実装の詳細なしで説明します(もちろん、必要に応じて追加できます)。MSBuildおよびMS Build Community Tasksの小さなスクリプトを書いたとだけ言います。これらのツールに精通していると思われる.NET開発者。



そのため、製品の現在のバージョンは3桁で、プレーンテキストファイルのSVNに格納され(XMLに格納)、製品開発者によって手動で変更されます。 製品バージョンの変更には、通常、リリース、リリースノート、ユーザー通知、サイトの更新などが続きます。



スクリプトによって実行される段階的なアセンブリ:

1. SvnCheckoutの作成

2.すべてのプロジェクトのAssemblyInfo.csのバージョンを、現在のバージョン+プロジェクトの対応するブランチのリビジョン番号に変更します。 たとえば、製品の現在のバージョンが1.3.2で、MySoundLibraryプロジェクトブランチのSVNリビジョンが286である場合、バージョンをAssemblyInfo 1.3.2.286に設定します。

3.ディストリビューション(InnoSetupがあります)では、ソリューションブランチ全体(.slnファイルが保存されているディレクトリ)のSVNバージョンを公開します

4.アセンブリを完了し、結果の.exe(.msi)ファイルにMyProduct_v_1_3_2_286.exeという名前を付けます

5.変更をコミットします。 重要:ソリューション内のすべてのプロジェクトのブランチは個別にコミットされます。



その結果、以下が得られます。

-「1つのボタン」の作成/ファイルの開始(CruiseControl.NETなどでハングアップ可能)

-ディストリビューションの各ビルドは、ファイル名の最後の桁のSVNリポジトリの状態を反映します

-ビルドのすべてのコンポーネント(.dll、.exe)は、プロジェクトの対応するSVNブランチの状態を反映します。 つまり たとえば、.dllファイルのバージョンを調べると、どのリビジョンからビルドされたかを確認できます。 変更を追跡することも便利です。最新バージョンの.dllファイルが大きいほど、変更が活発になります。



多分私は混chaとしすぎて、実装ではなくメソッドのみを提案しようとしました。車輪を発明しなかったことを望みます:)



All Articles