ビルド後に更新されたassemblyinfo.csファイルをチェックインすることは良い習慣ですか？
ビルドプロセスでは、すべてのAssemlyInfo.csファイルのバージョン番号が変更されるため、ビルドサーバーでバージョン番号を完全に管理できます。
現在、ビルドが成功した後、変更されたAssemblyInfo.csファイルをコミットします。 TeamCityの評価中に、コマンドラインからsvnを使用せずにそれを行う方法を見つけることができませんでした。
TeamCityには、バージョン管理に関連する多くの設定（ログイン資格情報の管理、ラベル付けなど）が用意されているため、「ビルド後の変更のチェックイン」などのオプションがないのはなぜですか。
それでは、ビルドサーバーでのビルド後に、更新されたassemblyinfo.csファイルをコミットすることをお勧めしますか？長所と短所は何ですか？
ビルドサーバーにバージョン管理への変更をコミットさせることによる大きなリスクの1つは、意図しないフィードバックループを非常に簡単に作成できることです。
多くの場合、バージョンコントロール（のトランク）へのコミットにより、ビルドサーバーでビルドが自動的にトリガーされます。ただし、ビルドサーバー自体も変更をコミットする場合、それ自体が継続的にトリガーされます。
通常、ビルドサーバーはビルド関連のメタデータ（ビルド日付、バージョン番号など）のみを変更するため、一般的な解決策は、実際のビルドプロセスを開始する前に、ビルドサーバーにその情報を含むファイルを生成させることです。
ビルドサーバーが生成できるもの以外の追加情報がファイルに含まれている場合、バージョン管理システムにはAssemblyInfo.csのテンプレートを含めることができ、ビルドサーバーは正しいバージョン/ビルドを置き換える/埋めるだけで済みます。情報。ローカルビルドの場合、ビルドをローカルビルドとして識別するビルド情報をテンプレートに入力するための事前ビルドステップを追加できます。
このようなテンプレートファイルを使用すると、AssemblyInfo.csの静的で手動で変更されたコンテンツは適切にバージョン管理されますが、ビルドシステムを実行するたびにそのファイルの無限のリビジョン変更が得られるわけではありません。