約1年前、当社は主に2人の上級開発者によって作成された比較的大きなソフトウェアパッケージをリリースしました。デモンストレーションを簡単にするために、これを「プロジェクトA」と呼びます。それ以来、私たちは新しいソフトウェアパッケージ「プロジェクトB」に取り組んでおり、そのツリーにはプロジェクトAのブランチがあります。
プロジェクトBにはプロジェクトAへの参照がありますが、プロジェクトBの終わりが近づいているので、AからBも参照する必要があります。したがって、Aのブランチをマージした後、Bと一緒に稼働する前に、 2つのプロジェクト間でコアライブラリをマージします。
この種の状況であなたが経験したことは何ですか？このプロジェクトで学んだいくつかのベストプラクティスと教訓は何ですか？プロジェクトAの残りのソースコードへの影響を最小限に抑えて、コアライブラリを最適にマージするにはどうすればよいですか？
編集： プロジェクトAの名前空間を保持しながら、プロジェクトBのコアライブラリ（最終的には会社のコアライブラリになる）にコードを配置することの実現可能性について、あなたはどう思いますか？そこから、レガシープロジェクトの新しい会社のコアライブラリを参照するだけです...
編集2： 返信ありがとうございます。たぶん、もう少し技術的な説明が必要です。これらのプロジェクトはどちらも非常に密接に関連していますが、それぞれにコアライブラリ用の独自の.NETクラスライブラリプロジェクトがあります。それを超えて、各ライブラリは他のさまざまな.NETプロジェクトによって参照されます。内部および外部のWebアプリ、フォームアプリなど。私の質問の多くは、ソースコードがどこにあるべきかということです。これらは、2つの別々の.NETプロジェクトのままである必要があるとは思いませんが、1つのプロジェクトに両方が含まれ、既存の名前空間を最初に保持します。 。開発を続けるにつれ、名前空間の組み合わせ、重複する機能のクリアなど、リファクタリングを行います。両方の既存のライブラリに含まれる機能が今後のプロジェクトで役立つことは間違いありません。また、既存の両方で共有する必要もあります。 「コア」ライブラリ。