13

他のオープンソースプロジェクトを依存関係として使用しているオープンソースMVC4プロジェクトを開始しました。他のプロジェクトをフォークし、必要に応じて変更します。私が直面している問題は、これらのプロジェクトを相互に依存させながら、別々に維持する方法です。それでも、私のプロジェクトをgitでプルする人は、依存関係プロジェクトも取得しますか？

  1. 他のプロジェクトのすべての関連コードを自分のリポジトリにスラムすることはできますが、この方法では、依存プロジェクトのフォークに貢献することはできません。私は自分のリポジトリの一部になります。本当にやりたくない。
  2. 他のプロジェクトを完全に個別に管理し、*。dllファイルを自分のプロジェクトにコピーできます。そして、依存するdllファイルをgitにコミットします。これは素晴らしいことですが、デバッグに依存するコードにステップインするとともに、2つのプロジェクトを同時に開発する能力を失います（* .pdbファイルをコピーする場合はそうではないかもしれません）
  3. ポイント2と同様に、依存プロジェクトからnugetパッケージをビルドし、それらをメインプロジェクトに追加できます。繰り返しになりますが、両方のプロジェクトを同時に開発することはできず、コンテキストを切り替える必要があります。
  4. いくつかの魔法で、私のリポジトリと依存リポジトリからのプロジェクトを組み合わせたソリューションファイルがあります。ビルドするたびに、依存するdllファイルを/libフォルダーにコピーしてコミットします。このように、別々のプロジェクト間でコンテキストを切り替える必要はありません。ただし、他の寄稿者が私のプロジェクトをgitプルすると、依存プロジェクトが取得されず、リポジトリにないプロジェクトを参照するため、ソリューションファイルが壊れてしまう可能性があります。

この場合、コードをどのように整理しますか？

4

3 に答える 3

6

通常、すべての依存関係に nuget を使用します。プロジェクトをフォークすると、それをナゲットとシンボル ソースにデプロイします。このようにして、依存関係のソースに問題なく入ることができます。

シンボル ソースとナゲットの詳細については 、「シンボル パッケージの作成と公開」も参照してください。シンボル ソースのデバッグを有効にするには、http://www.symbolsource.org/Public/Home/VisualStudioを参照してください。

Nuget package restoreを有効にすることも忘れないでください。

このソリューションでは、ソース コードを変更することはできませんが、少なくともデバッグすることはできます。

于 2013-03-13T11:41:50.093 に答える
1

コンセプトは CMake に似ていますが、完全に Visual Studio 内で使用しています。ソリューションに含めることができる、プロパティ ファイルの比較的知られていない機能があります。これにより、依存関係へのパスのみを含むファイルを作成し、可能なライブラリを含めて相対パスを設定し、含めることができない/含めたくない他の依存関係に適切なパスを設定するように人々に要求することができます。

ちょっとした作業でかなりきれいになり、TeamCity や他の同様のツールを使用して自動化するのは非常に簡単です (各ビルド エージェントは変数を設定して、依存関係を保持する場所を示すことができます)。

小規模な依存関係と、私のプロジェクトで動作するように微調整された依存関係については、アーカイブまたはルーズ ファイルをリポジトリに保持し、プロパティ ファイルを使用してそれらを参照します。他の人は、それらを見つける場所とパスを編集する方法について説明しています。

このようなアプローチに興味がある場合は、さらに詳しく説明できます。プロパティファイルは十分に文書化されていないため、理解するのに少し手間がかかりましたが、かなりうまく機能しています.

于 2013-03-15T20:29:36.120 に答える
0

循環依存関係を作成していない場合は、次のアイデアがあります。

  1. ソリューションにClass Library一意の名前で新しいプロジェクトを追加します。ClassLibrary1

  2. Buildそのプロジェクト設定のページで、Output pathアプリケーション出力パスへの構成

  3. ページで、ブロックBuild Eventsする次の行を追加します。Post-build event command line

    del "$(TargetPath)"

  4. 手順 1 から 3 を繰り返しますが、別の名前、たとえばClassLibrary2、および configOutput pathをソース パスに付けます。ClassLibrary1

  5. のセットProject Dependancies、ClassLibrary1オンにチェックClassLibrary2

  6. へのプロジェクト参照として他のすべてのプロジェクトを追加し、デフォルト値ClassLibrary2のままにしますCopy Localtrue

  7. 一度ビルドするClassLibrary2と、すべての DLL が のソース パスにあります。ClassLibrary1

  8. それらを参照に追加し、デフォルト値のClassLibrary1ままにしますCopy Localtrue

  9. アプリケーションのセットと、循環依存関係Project Dependanciesを引き起こさない他のすべてのプロジェクト、オンにチェックClassLibrary1

  10. DLLが配置されたパスから、他のプロジェクトの参照を追加しますClassLibrary1

  11. Copy Local他のプロジェクトに追加されたこれらすべての DLL のセットfalse

したがって、プロジェクトClassLibrary1は、ソリューションの外部ライブラリの集中管理になります。アプリケーションをビルドするたびにRebuild Solution(またはアプリケーションをビルドするだけで)、ClassLibrary1アプリケーションの出力フォルダーへの参照に追加された最新の DLL をコピーし、それ自体が生成した という名前の DLL を削除しますClassLibrary1.DLL。コンパイル時または実行時のアプリケーションと依存関係は、同じバージョンの DLL を使用するため、追加のデプロイを行ったり、各デプロイをチェックしたりする必要はありません。

于 2013-03-15T20:22:57.370 に答える