2

通常、「継続的なパッケージ統合」には、ソース管理、ビルドサーバー、および参加チームが更新されたパッケージを好きなだけフェッチすることが含まれます。しかし、私はこのストーリーのより極端なバージョンを探しています-CMなしで-完全に開発者のマシンで、すべて一挙に行われます。私が欲しいもののより詳細な説明はこのようになります...

Visual Studio 2010または2012を使用して、プラグインシステムを実装する「foo.csproj」アプリケーションを想定します。各プラグインはnugetパッケージを表し、対応するVisualStudioプロジェクトがあります。これらの各プロジェクトは、基本アプリケーションを含む同じVSソリューションの一部です。

次の開発ストーリーが必要です。

  1. プラグインのソースコードを変更します。
  2. ソリューションをビルドするか、デバッグ起動を実行します。これにより、msbuildは...
    1. 変更したプラグインを再構築します
    2. 次に、nugetは各プラグインをパッケージ化して、ローカルリポジトリ（VSソリューションの単なるサブフォルダーにすることができます）にアップロードします。
    3. ベースアプリケーションを再構築します。
    4. 前の手順で更新されたベースアプリケーションのnuget-plugin依存関係を更新します。 注：
      1. これは、MSBuildが、すべてのプラグインがビルド、パッケージ化、およびアップロードされるまで、この最後の手順を実行しないことを魔法のように知っていることを前提としています。
      2. 「foo」アプリケーション自体がnuget.coreを使用してパッケージを更新できますが、この場合、VSビルドプロセスがこの手順を実行したと想定しています。

このストーリーが十分に一般的であり、このための「一般的な」（msbuild？）スクリプトがあるかどうかを知りたいです。

これがどのように扱われるべきかについての私自身の推測は次のとおりです。

  1. すべてのプラグインプロジェクトは、VSソリューションフォルダー構造のどこかにある共通の「プラグイン」フォルダーに配置されます。
  2. 基本アプリケーションの「プロジェクトの依存関係」は、すべてのプラグインプロジェクトへの参照を使用して構成されます。 注：これらのプロジェクトの依存関係を手動で管理するというアイデアは好きではありません。
  3. 基本アプリケーション「foo.csproj」には、「foo.csproj」XMLをスキャンして「plugins」フォルダーにある依存関係を探し、それぞれのnugetパッケージ化とデプロイを開始するビルドステップがあります。
  4. 次に、ベースアプリケーションは、nugetの「すべて更新」を開始します。うまくいけば、msbuildがすでに実行中の途中であっても、これが可能です。

つまり、ベースアプリケーションは、変更されたプラグインを即座に使用できます。これは、チェックイン、ビルドサーバー、またはプラグインパッケージを更新するための手動および任意の要求なしで実行されます。

このストーリーの既存のスクリプトがまだ存在しない場合は、自分で作成します。しかし、私はまだ知りたいです：

  1. すぐ上のステップ2を一般的なものに変換できますか？つまり、特定のフォルダー内のすべてのプロジェクトが既にビルドされるまで、「ベースアプリケーション」をビルドしないようにmsbuildを説得するにはどうすればよいですか？プロジェクトの依存関係を手動で管理したくないことを忘れないでください。
  2. この全体的なアプローチに欠陥はありますか？

私が見落としているかもしれないこの話を支援する既存のnuget-visual-studio統合があるかどうかを知ることに特に興味があります。

4

1 に答える 1

3

これは答えるのにかなり長い質問なので、これですべてをカバーしているのかどうかはわかりません。私は自分のベストを尽くします。まず、あなたのシナリオは珍しいことではありません。計画されたアプローチの最初の2つのステップは、私には問題ないようです（プラグインプロジェクトの場所は自由に選択できます）。

確かなことの1つは、ビルド順序を手動で定義する必要があることです。ソリューションは、（NuGet）プラグインを消費するプロジェクトが、それらのプラグインのソースコードを含むプロジェクトに依存しているかどうかを認識していないためです。Visual Studioに組み込まれている[ビルド順序]ダイアログを使用する代わりに、MSDNブログのこの投稿を参照して、これを行う正しい方法を確認してください（または、ローカルでは機能するがビルドサーバーでは機能しないものになる可能性があります）。参照された投稿の主要なMSBuild要素は次のとおりです。

<ProjectReference Include="... foo.csproj"> 
    <ReferenceOutputAssembly>false</ReferenceOutputAssembly> 
</ProjectReference>

さて、これらのプラグインのパッケージ化、展開、および消費については、次のとおりです。

  • 各プラグインプロジェクトは、ビルド後のステップでパッケージの作成と公開をトリガーする必要があります。私のブログのこの投稿には、始めるために使用できるMSBuildのものがたくさん含まれているZIPダウンロードが含まれています。たとえば、リリースビルドのクラスライブラリのNuGetパッケージをバージョン管理、パッケージ化、公開します。NuGetコマンドラインツールを使用して、パッケージpack（コマンドリファレンス）とpush（コマンドリファレンス）を使用しています。
  • 消費するアプリケーションプロジェクトは、ビルド前のステップで実行する必要がありますNuGet.exe update <packages.config>（コマンドリファレンス）。

また、ビルドを並行して実行していないことに注意してください。

于 2012-12-29T20:16:04.323 に答える