次のシナリオがあります。アプリケーションは、IDEとビルドスクリプトを介してビルドされます。ビルドスクリプトは、初期設定（依存関係の取得、環境の設定）、バイナリの生成、および継続的インテグレーションプロセスに使用されます。バイナリにAssemblyFileVersionとしてビルドの月日を設定し、リビジョンにsvnリビジョンを設定する必要があります。これにより、AssemblyInfo.csがリビジョンごとに変更され、ソース管理ログに多くのノイズが発生します。ファイルは無視できますが、セットアップの一環として、ファイルを再生成する必要があります。
他に何かアイデアがあるかどうか、この場合はどうしますか？
今、私はアンディ・ホワイトの答えに触発された解決策に落ち着いています:
欠点：
AssemblyInfo.csの一般的な方法は、静的ファイルを保持するのではなく、ビルドプロセスの一部として動的に生成することだと思います。
を生成することにより、任意の/構成可能な設定を使用できます。
NAntには<asminfo>この目的のためのタスクがあると思います。MSBuildにも似たようなものがあると思います。または、カスタムファイル生成スクリプトを記述し、それを使用してカスタムAssemblyInfo.csをビルドに追加することもできます。
RTM / RTW / GA /（Whatever:)リリースビルド後にのみトランクのAssemblyInfoを更新します。
Nightly / Beta / RC / QA /（Whatever :)ビルドは、更新されたAssemblyInfo.csのコピー（CIサーバー上の作業コピーから）を適切なブランチまたはタグに取り込むだけです。Subversionを使用しており、コミットされていない変更を加えた作業コピーでブランチ/タグ付けを行うことができます。
これにより、Nightly / Betaビルドの正しいバージョンのAssemblyInfoをブランチまたはタグに保持し、最終リリースが行われた後にのみトランクのAssemblyInfoにタッチすることができます。ビルドサーバーには、このタイプのビルドでトランクにこれをコミットするように指示するスイッチがあります。
FWIWでは、ビルドサーバー（CruiseControl.NET）から渡された、プロジェクトタイプごとに設定されたプロパティに異なる値を使用して、すべてをMSBuildスクリプトから駆動します。
[編集]また、開発者のバージョンのAssemblyInfoは更新されないため（手動で変更しない限り）、ビルドごとに変更されたAssemblyInfoのノイズが発生しないことにも注意してください。開発者がMajor.Minorを制御し、ビルドサーバーがBuildを制御し、QAのリビジョンを独自のシステムにリンクするようにします（WiX / MSIでは無視されるため）。
また、生成ステップを使用してAssemblyInfo。[cs | vb]ファイルを作成しますが、ファイルのテンプレートコピーをソースとして使用し、小さなPerlスクリプトを使用してそのテンプレートを解析し、バージョン文字列を置き換えて生成します。最終出力。
このシステムの問題は、VBプロジェクトが常にAssemblyInfoファイルをロードしているように見えることです。つまり、PreBuildステップを実行してAssemblyInfo.vbファイルを作成する前であっても、プロジェクトが最初にロードされるときにエラーが発生します。その問題の解決策はまだ見つかっていません-誰かが洞察を持っているなら、私はそれを聞いてみたいです...
変更されたAssemblyInfo.csをソース管理にチェックインしない場合、なぜノイズが発生するのでしょうか。
ビルド全体でAssemblyFileVersionの単一の値を使用することをお勧めします。また、そのバージョンを含む単一のファイルをチェックインするか、ビルドにバージョン番号のラベルを付けることをお勧めします。そうすれば、変更された複数のAssemblyInfo.csファイルをチェックインする必要がなくなります。