11

かなりの数のソリューションで使用されるコードを含むプロジェクト「MyFramework」があるとします。各ソリューションには、独自のソース管理管理 (SVN) があります。

MyFramework は内部製品であり、正式なリリース スケジュールはありません。ソリューションについても同様です。

DLL をビルドして 12 個のプロジェクトすべてにコピーする必要はありません。つまり、新しい開発者はsvn-checkoutを実行するだけで作業を開始できるはずです。

これらすべてのソリューションで MyFramework を共有する最善の方法は何ですか?

4

7 に答える 7

7

SVNについて言及したので、外部を使用して、フレームワークプロジェクトを、それを使用する各ソリューションの作業コピーに「インポート」できます。これにより、次のようなレイアウトになります。

C:\Projects
  MyFramework
    MyFramework.csproj
    <MyFramework files>

  SolutionA
    SolutionA.sln
    ProjectA1
      <ProjectA1 files>
    MyFramework   <-- this is a svn:externals definition to "import" MyFramework
      MyFramework.csproj
      <MyFramework files>

このソリューションでは、MyFramework を使用する各ソリューションで MyFramework のソース コードを利用できます。利点は、MyFramework のソース コードをこれらの各ソリューション内から変更できることです (別のプロジェクトに切り替える必要はありません)。

しかし、同時に、これは大きな欠点でもあります。なぜなら、MyFramwork を別のソリューションに変更するときに、一部のソリューションの MyFramwork を非常に簡単に壊してしまうからです。

このため、私は最近そのアプローチをやめ、フレームワーク プロジェクトを完全に別のソリューション/製品 (独自のリリース スケジュールを持つ) として扱っています。他のすべてのソリューションには、フレームワーク プロジェクトの特定のバージョンのバイナリが含まれます。

これにより、フレームワーク ライブラリに加えられた変更によって、ライブラリを再利用しているソリューションが壊れないようになります。ソリューションごとに、新しいバージョンのフレームワーク ライブラリに更新する時期を決定できるようになりました。

于 2009-05-29T13:10:58.993 に答える
4

それは惨事のように聞こえます...開発者が他の人の作業を元に戻したり壊したりすることにどのように対処しますか...

私があなたなら、MyFrameWork を完全に別のソリューションに入れます。開発者が 12 のプロジェクトの 1 つを開発したい場合、そのプロジェクト ソリューションを 1 つの IDE で開き、別の IDE で MyFrameWork を開きます。

MyFramework アセンブリと GAC に厳密な名前を付けて、他のプロジェクトで参照する場合、「DLL のコピー」は問題になりません。

MyFrameWork をビルドするだけで (PostBuild イベントで GacUtil を実行してアセンブリ キャッシュに入れることができます)、それから他のプロジェクトをビルドします。

于 2009-05-29T13:05:33.653 に答える
2

「最善の方法」は環境によって異なります。私は、TFS ベースの継続的インテグレーション環境で作業を行いました。この環境では、夜間ビルドによってバイナリが共有にデプロイされました。すべての依存プロジェクトが共有を参照していました。これが遅くなったとき、開発者がプロ​​ジェクト ファイルを変更せずに共有バイナリのローカル コピーを使用できるようにするツールをいくつか作成しました。

于 2009-05-29T13:13:06.600 に答える
2

いくつかの規則に従えば、svn:externalsはこれをうまく処理します。

まず、svn:externals の定義に相対 URI (^ 文字で始まる) を使用し、可能であればプロジェクトを同じリポジトリに配置すると安全です。これにより、Subversion サーバーが新しい URL に移動した場合でも、定義は有効なままになります。

次に、SVN book の次のヒントに従ってください。svn:externals 定義で PEG-REV を使用して、ランダムな破損や不安定なタグを回避します。

すべての外部定義で明示的なリビジョン番号を使用することを真剣に検討する必要があります。そうすることで、外部情報の別のスナップショットをいつ取得するか、どのスナップショットを取得するかを正確に決定できるようになります。明示的なリビジョン番号を使用すると、サードパーティのリポジトリに変更が加えられて自分では制御できないという驚きを回避できるだけでなく、作業コピーを以前のリビジョンにさかのぼると、外部定義も元の状態に戻ることになります。その前のリビジョンで...

于 2009-05-29T17:07:20.583 に答える
2

12 のソリューションのいずれかで機能するには、「フレームワーク」コードを定期的に変更する必要がありますか?

その場合、フレームワークはおそらく新しく作成されたばかりなので、すべてのソリューションにフレームワーク プロジェクトを含めます。結局のところ、フレームワークのコードを変更する必要がある場合は、簡単に変更できるはずです。

1 つのソリューションから行われたフレームワークの変更は、他のすべてのソリューションに影響を与えるため、中断が発生し、それらに対処する必要があります。

ソリューションで作業するときにフレームワークを変更する必要がほとんどない場合 (これが目標になるはずです)、代わりにフレームワーク dll への参照を含め、必要に応じて各ソリューションの dll を更新します。

于 2009-05-29T13:23:48.233 に答える
1

スケーラブルなソリューションは、ソリューション ディレクトリでsvn-externalを実行して、インポートしたプロジェクトが他のプロジェクトと並行して表示されるようにすることです。その理由を以下に示します。

「インポートされた」プロジェクトに別のサブディレクトリを使用すること、たとえばexternalssvn-external を使用することは、プロジェクト間の重要な依存関係が発生するまでは良い考えのようです。たとえば、プロジェクト A がプロジェクト B のプロジェクトに依存し、プロジェクト B がプロジェクト C に依存しているとします。その後、プロジェクト A のソリューション S がある場合、次のディレクトリ構造になります。

# BAD SOLUTION #
S
+---S.sln
+---A
|   \---A.csproj
\---externals
    +---B     <--- A's dependency
    |   \---B.csproj
    \---externals
        \---C     <--- B's dependency
            \---C.csproj

この手法を使用すると、ツリー内に 1 つのプロジェクトの複数のコピーが作成されることさえあります。これは明らかにあなたが望むものではありません。

さらに、プロジェクトがNuGetの依存関係を使用している場合、それらは通常packages最上位のディレクトリに読み込まれます。これは、サブディレクトリ内のプロジェクトの NuGet 参照externalsが壊れることを意味します。

また、SVN に加えてGitを使用する場合、変更を追跡するための推奨される方法は、プロジェクトごとに個別の Git リポジトリを用意し、その中git submoduleのプロジェクトを使用するソリューション用に個別の Git リポジトリを用意することです。Git サブモジュールが親モジュールの直下のサブディレクトリでない場合、Git submodule コマンドは直下のサブディレクトリであるクローンを作成します。

すべてのプロジェクトを同じレイヤーに置くことのもう 1 つの利点は、すべてのソリューション (Git または svn-external 経由で追跡) からのプロジェクトを含む「スーパー ソリューション」を作成できることです。単一のソリューション - 単一のプロジェクトに加えた変更が他のすべてのプロジェクトと一致するように再構築します。

# GOOD SOLUTION #
S
+---S.sln
+---A
|   \---A.csproj
+---B     <--- A's dependency
|   \---B.csproj
\---C     <--- B's dependency
    \---C.csproj
于 2013-10-03T09:10:08.483 に答える
1

私は別のポスターに同意します-それは問題のように聞こえます. しかし、「正しい方法」でやりたくない場合は、他に 2 つの方法を考えることができます。以下の番号1に似たものを使用しました。(ネイティブ C++ アプリの場合)

  1. スクリプト、バッチ ファイル、または依存関係の取得と構築を実行するその他のプロセス。(一度だけ) これは、リポジトリに変更がない場合にのみビルド/実行されます。取得するタグ/ブランチ/バージョンを知る必要があります。プロジェクト ファイルのビルド前のステップとして、bat ファイルを使用できます。

  2. リポジトリにバイナリを保持します (良い考えではありません)。この場合でも、依存プロジェクトは取得を行う必要があり、取得するバージョンを知る必要があります。

最終的に、私たちがプロジェクトでやろうとしたことは、サードパーティのライブラリを使用および参照する方法を模倣することでした.

できることは、それ自体へのパス環境変数を設定する依存関係のリリース パッケージを作成することです。マシン上に複数のバージョンが存在することを許可し、依存プロジェクトが特定のバージョンをリンク/参照します。

何かのようなもの

$(PROJ_A_ROOT) = c:\mystuff\libraryA

$(PROJ_A_VER_X) = %PROJ_A_ROOT%\VER_X

次に、特定の名前またはバージョン環境変数を使用して、依存ソリューションで必要なバージョンを参照します。

きれいではありませんが、うまくいきます。

于 2009-05-29T13:08:56.033 に答える