C＃gitプロジェクトで依存関係の複数のソースコピーを作成するにはどうすればよいですか？
当社では、クライアントサーバーモジュール方式のC＃.NETで情報システムソフトウェアを開発しています。モジュールプロジェクトはサーバー/クライアントプロジェクトに直接依存せず、共有パーツにのみ依存します。したがって、コアプロジェクトの構造は、依存関係を含めて次のようになります。
- serverは[.____に依存します。]
- server-sharedライブラリ
- common-sharedライブラリ
- クライアントは依存します
- client-sharedライブラリ
- common-sharedライブラリ
そしてモジュール構造は次のようになります：
- モジュールはに依存します
- server-sharedライブラリ
- client-sharedライブラリ
- common-sharedライブラリ
私たちはGitを使用し、依存関係はサブモジュールを使用して配置されます。しかし、これは「サブモジュール地獄」につながります-純粋なクライアントとサーバーのみを含むプロジェクトでは、すでにいくつかのライブラリ（common-shared）が2回あります。したがって、クライアントとサーバーを同時に実行すると、一度に1つの「コピー」しか変更できず、バージョンの非互換性につながるため、それらの開発は困難です。
モジュールはライブラリのコピーを増やすだけなので、モジュールはさらに複雑で使用できなくなります。一部のモジュールが不正なバージョンのライブラリでビルドされている場合、クライアントとサーバーとの非互換性につながる可能性があります。
One言及できる解決策は、プロジェクトをディレクトリツリーの上位レベルのライブラリに依存するように設定することですが、それは誤解です。また、CIを使用してリポジトリを構築することもできなくなります。
2番目ソリューションはモノレポですが、GitLabインスタンスの問題を個別に追跡する可能性がなくなります...
番目ソリューションはNuGetを使用している可能性がありますが、ライブラリプロジェクトが開発不可能になります（個別に開発するには、「テストプロジェクト」を作成する必要があります）。
このコードベースに最適なソリューションは何ですか？
どうもありがとうございました！
私は常にこの問題をNugetを使用して回避しています。 .netを開発している場合、その「標準」はそのまま使えるパッケージマネージャーであり、非常にうまく機能します。
ある場合の欠点は、依存関係がソースコードではなくバイナリdllになり、デバッグしながら編集できることです。
これは、日常の作業方法にいくつかの制限を課します。ビジュアルスタジオなどの複数のコピーを開く必要があります。一般的な問題には多くの回避策がありますが、私の考えでは、すべてを1つにまとめるのと同じくらい簡単にすることができます。解決。
しかしながら！私は強くこれらの依存関係を分離し、バイナリ出力のみを消費することで、より良い実践を強いられると主張します。
ユニットテスト。依存プロジェクトを作成するときにコードを微調整するだけではできないため、ライブラリが独自のプロジェクトで正しく動作していることを確認する必要があります。
バージョン管理。 Nugetライブラリにはバージョンが必要です。各ライブラリには、はっきりと見える独自のバージョンがあります。
CI。パブリッシュ/バージョニングの要件により、ビルドサーバーでの自動ビルドに向けて
単体テストとバージョン管理を実施すると、プロジェクトの範囲を実際の機能領域に限定する必要があることが明らかになります。ほんの1ビットしか変更されていなくても、1時間ごとに新しいバージョンを取得する「共通共有」はもうありません
完成したライブラリと完了したライブラリ。コードをスコープに分割し、独自の単体テストを行うことで、実際にコードの一部を完成させることができます。依存関係を常に微調整するのではなく、依存関係を消費する一部のアプリを少し簡単にする一方で、知らない10個の他のアプリを壊します。
ただし、このアプローチの最も強力な主張は、他のすべての人がそれを行っているということです。 NewtonSoft.JsonやSystem.Configurationをデバッグできないことを心配する必要はありません。dllを使用して生活を始めるだけです。
ライブラリは、毎日使用する公開されたライブラリと同じくらい使いやすく、信頼できるものにするよう努力する必要があります。