1

展開/リリースシナリオでGACUtil を使用しないことに関する情報/ブログ/msdn 記事がたくさんあり、MSI または別の Windows インストーラー テクノロジがはるかに優れたオプションです。

ただし、開発ワークフローで GACUtil を使用することは依然として適切ですか。

強力な名前が付けられ、GAC から参照される DLL が多数あります。開発チームの同期を維持するために、GAC 対応 DLL の新しいバージョンが生成されると、毎日のトランク チェックアウトの一部として、他のすべての開発者 GAC に自動的に追加されます。ワークフローは次のようになります。

  • 開発者は、GAC 対応アセンブリの 1 つに変更を加え、ローカルでテストし、サインオフしたら、DLL のリリース バージョンをコンパイルします。
  • リリース バージョンは、\Project_DIR\bin\Release*.dll -> \COMPANY_GAC\Current*.dll からコピーされます。
  • 他の開発者は、ソース管理チェックアウト バッチ スクリプトを実行します。
    • COMPANY_GAC\Current*.dll の最新バージョンを確認してください
    • 各 DLL で GacUtil.exe を実行します。

これまではこれでうまくいきましたが、以下の点で少し複雑になってきています: - より大きなチーム、より厳格な GAC 変更の管理。- CLR2.0 および CLR4.0 でコンパイルされた Company_Gac アセンブリには、異なるバージョンの GACUtil.exe が必要です - 複数の機能ブランチを持つビルド/統合サーバーでアセンブリを管理する (したがって、異なる GAC DLL をホットスワップする必要があります)

これを管理するために、GACUtil & Scripts よりも堅牢なものを検討する必要がありますか?

考慮事項の 1 つは、powershell で何かを自分でロールして、アセンブリの種類を確認し、アセンブリを正しい GAC に追加することでした。誰かがこれをしましたか？

開発者が GAC ワークフローを管理する方法に関するその他の提案は大歓迎です。

4

1 に答える 1

2

展開中に gacutil.exe を使用しないのは簡単です。これは Windows SDK ユーティリティであり、再配布可能なコンポーネントではないため、ターゲット マシンでは使用できません。

開発中にそれを使用することは確かに一般的ではありません。最も一般的なのは、依存プロジェクトが含まれているソリューションを使用して、GAC を必要とせずにローカル デプロイで最新のビルドを自動的に取得できるようにすることです。ソリューションが大規模になりすぎると、ビルド時間に剣の配布を開始することが必要になる場合があります。

それ以上の魔法の解決策はありません.GACは確かにビルド時間を再び短縮するのに役立ちます. 一般に、基盤アセンブリのチャーンはマイナス 1000 ポイントから開始する必要があり、多くの苦痛を引き起こす可能性があります。たとえば、毎週のリリース更新のためにそれらを保存します。一方で、これらすべてのものをクライアント マシンに適切にインストールするというコア ニーズもあります。誰もまだそれに集中していない場合は、今がその堅実さを得るのに良い時期かもしれません. 誰もがそれを使用して自分のマシンで必要なアセンブリを取得すると、自動的にデバッグされます。

于 2012-08-13T18:51:23.933 に答える