3

私はまだ.NET(特にC#)を学んでいますが、マルチプロジェクトソリューションを使用するよりも、dllを作成して参照することの利点に興味がありますか?どちらかを行う機会がありますが、どちらが良いかわかりません。dllになるプロジェクトはかなり小さいですが、再利用される可能性があります。この決定を行う際には、サイズと再利用性を考慮に入れる必要がありますか?助けてくれてありがとう。

4

5 に答える 5

4

各プロジェクトがアセンブリを生成するため、技術的には他のアセンブリを参照しています。

マルチプロジェクトソリューションを使用する利点の1つは、2つの異なるソリューションを構築する必要がないことです。両方のプロジェクトのコードを変更すると、ソリューション全体が1つのステップで構築されます。また、両方のプロジェクトを同時にデバッグすることもできます(これは別々のソリューションで可能ですが、注意が必要です)。

サイズはビルド時間の要因になる可能性がありますが、サイズが大きくない限り、大きな問題にはなりません。プロジェクトが他のソリューションで使用されている場合は、ビルドプロセスをより適切に制御できるように、プロジェクトを別々のソリューションに保持することが理にかなっている場合があります。

スタック全体でインターフェイスを変更するのは適度に難しいため、個別のソリューションを使用すると、インターフェイスを一定に保つのにも役立ちます。

于 2012-07-31T13:46:30.990 に答える
1

アセンブリが他のプロジェクト間で共有されない場合は、同じソリューションでそれらを使用するだけです。

異なるプロジェクト間でコードが共有されている場合。プロジェクト間で共有されるコードは、他のサードパーティのバイナリと同じように扱う傾向があります。つまり、特定のバージョンのDLLのコピーを取得し、DLLを参照します。

その利点は、コードを共有する両方のプロジェクトが異なるリリーススケジュールにある場合、6か月または1年後に、共有コードの更新と潜在的な処理のヒットがいつ発生するかをそれぞれが完全に制御できることです。破壊的な変化。

共有コードをプロジェクトに直接組み込んだばかりの場合は、他のプロジェクトに必要な変更に翻弄されます。これは適切な場所ではありません。

于 2012-07-31T13:52:34.150 に答える
1

各プロジェクトはそれ自体のアセンブリを出力しますが、プロジェクトをグループ化すると、デバッグとビルドが簡単になります。

将来、個々のプロジェクトを再利用できると確信している場合は、マルチプロジェクトソリューションから始めてください。相互依存を最小限に抑えるために、プロジェクトを慎重に設計してください。これをうまくやれば、後日、ソリューション全体から独立して個々のプロジェクトを開発したいと思ったときに、それらを分離するのはそれほど難しくありません。

于 2012-07-31T13:49:52.300 に答える
0

あなたが最初に消費するプログラムを開発しているとき、私はマルチプロジェクトソリューションを持つのが最も簡単だと思います。ただし、後で同じdllを使用する別のプログラムを開発する場合は、tehmを参照してください。

于 2012-07-31T13:47:31.577 に答える
0

ライブラリプロジェクトを追加し、同じソリューションでプロジェクトを参照することをお勧めします。プロジェクト参照を使用してライブラリプロジェクトを参照します。これは、コードのデバッグと保守を改善するのに役立ちます。

于 2012-07-31T13:49:20.080 に答える