問題タブ [version-numbering]

TeamCityをCIサーバーとして使用しており、リリースをバージョン管理するための安全な（つまり、人為的エラーの可能性を最小限に抑える）方法を実装する方法を考えていますが、必要な労力も最小限に抑えられています。これまでのところ、以下が最も論理的であるように思われます。

1. バージョンファイルを作成します（またはassemblyinfo.csを使用します）。バージョン情報は...の形式になります。このファイルは私のVCSにチェックインされます。
2. TeamCityビルドを実行する
3. TeamCityは、手順1からバージョンファイルを読み取り、個々の番号を選択して、対応するTeamCityビルドパラメーターを設定します（後で、nugetパッケージの作成やラベル付けなどに使用できます）。
4. TeamCityは、最終的な「ビルドカウント」値を自動的にインクリメントします。
5. TeamCityは、新しいバージョン情報をバージョンファイルに保存します（更新された「ビルドカウント」を使用）
6. 次に、TeamCityは、残りのビルドステップ、ファイルのビルド、単体テストの実行、正しいアセンブリバージョンの設定などを実行します。
7. TeamCityは最終的にファイルをVCSにチェックインします

この方法の利点は、古いリリースの修正を行う必要がある場合、バージョン番号が正しくなり、TeamCityが古いバージョンのファイルを操作して、通常どおりビルドカウントを増やすことができることです。これは、メジャー/マイナー/パッチバージョンを正しく更新していることを前提としています。これは、カスタムビルドダイアログを介してビルドするブランチを選択できるTeamCity7.1のまもなくリリースされる機能とうまく機能することを願っています。

私がこれまで読んだことから、この種の操作はTeamCityで可能であるはずですが、私たちは2人の衣装であり、多額の投資をする余裕がないため、これを修正するための最も簡単なルートを探していますNantまたはPowerShellのエキスパートになって、それが私たちの望むことを実行できない可能性があることを見つけるまでの時間。

だから私の質問を要約すると次のようになります：

1. 私が提案していることは可能ですか？
2. はいの場合、Nant、PowerShellなどの私の限られた経験を考えると、使用するのに最適なツールは何ですか（つまり、コマンドラインとスクリプトの経験が単純なDOS操作と少しのVBScriptにまで及ぶ人にとって最も早く学ぶことができます）

どんな助けでも大歓迎です。

5つのプロジェクトでソリトンを開きたい場合、1つのプロジェクトで次のようなエラーが発生します

「\AssemblyInfoTask\Microsoft.VersionNumber.targets」が見つかりませんでした。宣言内のパスが正しいこと、およびファイルがディスク上に存在することを確認してください。

何が問題なのか？

Visual C ++プロジェクトには、バージョンにDOTSの代わりにCOMMASを使用する次の宣言があることを確認しました。

ここにあるMSの記事にも、コンマを使用した同じ値があります（実際、上記の宣言はその記事に基づいています）。ここでCOMMASを使用するのはなぜですか？コンパイルされたファイルのプロパティを開くと、FileVersionは11.0.2.0と表示されますが、ProductVersionは11,0,2,0と表示されます。これについては、QAの友人がバグだと言っています:)。私が見逃している標準的なメカニズムや内部メカニズムはありますか？

ソリューションを継続的統合 tfsbuild 2010 サーバーに統合しました。これは、すべてのライブラリを構築するのにうまく機能します。

次に、CI サーバーでビルドするたびにバージョン番号を増やしたいと思います。

バージョン番号の構成は、(メジャー バージョン).(マイナー バージョン).(リビジョン番号).(ビルド番号)です。

私の質問は、このシナリオでインクリメントする必要がある数値としてのベスト プラクティスは何ですか? ビルド番号は 1.1.1.123 になり、次のチェックインの結果は 1.1.1.124 などになると考えていたでしょう。

リビジョン番号がインクリメントされるのはいつですか？メジャーはメジャー リリースのマニュアルであり、マイナー バージョンはリリース用に複数のブランチを作成するためです。

私は正しいですか、それとも正しい慣行は何ですか?

私の目標は、WIX 3.6 プロジェクトで出力 msi ファイルにバージョン番号を付けて自動命名することです。次のリンクを見つけました: WiX の自動インストーラーのバージョン番号を再訪しましたが、少し異なるシナリオがあります: アセンブリのバージョン番号を参照して製品のバージョン番号を制御したくありません。代わりに、wix ファイルに割り当てたいだけです。具体的には、次のようなプロパティを定義する wxi ファイルがあります。

その結果、Product.wxs ファイル内の任意の場所でこの VersionNumber 変数を使用できます。しかし、出力 msi ファイルの名前を変更する最も簡単な方法は、MSBuild にビルド後のタスクを追加することだと思われるため、この VersionNumber を MSBuild プロジェクト ファイルに渡す必要があります。これが私を止めるものです。

MSBuild で VersionNumber 定数を定義し、それを WIX 内で使用するという逆の方法を試しました。さまざまなビルド/プラットフォームの組み合わせでこの定数を同じに保つ必要があることを除いて、問題なく動作します。VS IDE でソフトウェアをビルドしています。つまり、IDE のウィンドウでバージョン番号を変更すると、特定のビルド/プラットフォームの組み合わせにのみ適用され、他の組み合わせは変更されません (コマンド ラインからビルドしているかどうかはわかります。バージョン番号を渡すだけで、既存のものを上書きできます)。そして、それは私が見たくないものです。間違いを避けるために、バージョン番号を 1 か所で定義するというアイデアが気に入っています。

どんな助けでも大歓迎です！

ClickOnce アプリケーションの発行で自動的に増加するビルド/バージョン番号があります。このバージョン番号は、プロジェクト プロパティのアセンブリ バージョンとは異なります (これは、生成された WPF の [About] ボックスに自動的に表示されます)。

アセンブリ プロパティで ClickOnce のバージョン番号とプロジェクト番号を同期する方法はありますか? 目標は、両方の場所で自動的に増加する同一のバージョン番号を取得することです。

シナリオ: RSS フィードをチェックし、利用可能な新しいバージョンがあるかどうかを調べる単純なアプリケーションがあります。したがって、現在のバージョンが RSS フィードにあるバージョンよりも古いかどうかを確認したいと思います。理想的には次のように単純です。

問題:バージョニングは major.minor.revision.build で構成されていますが、これを解析してバージョン チェックを実行する方法がわかりません。

比較するパラメータは次のとおりです。

Web からダウンロードしたバージョンは"0.2.6.1"(文字列として) です。

一方が他方よりも小さいかどうかを確認する最良の方法は何でしょうか?

double に変換してみましたが、値は 0.2 になります (最初の . のみが解析され、残りは無視されます)。

制約: .NET フレームワークが存在しない場合でもアプリケーションが動作する必要があるため、.NET ライブラリを使用したソリューションであってはなりません。

（編集） Karthik Tの回答のおかげで、次の解決策に落ち着きました。

私は他の言語でこの問題に対する多くの答えを見ていますが、文字列として与えられた2つのバージョン番号を比較する方法を見つけようとしています。例えば

文字列内の整数値を比較して、どちらが大きいかを確認する方法を見つけようとしています。（この場合、str1の方が大きくなります）。atoiやstrtokと組み合わせて使うことを考えましたが、一度に2つの文字列をトークン化することはできません。何かアドバイス？

vb6 ( VPIaccessMaker.vbg) から完全なバージョン番号を設定する方法 ()、Visual BasicからMajor.Minor.Revision を 3.2.2 に設定できます。その場合、exe のバージョンは 3.2.0.2 になります。 1.2 .