私の現在の .net プロジェクトでは、さまざまな .dll ファイルを使用しています。今、私は、さまざまなソリューションやプロジェクトでさまざまな .dll ファイルを処理し、それらを SVN と連携させて、さまざまな開発者が使用できるようにするためのベスト プラクティスは何かを自問しています。
さて、私はいくつかの一般的なヒントについて尋ねています：
ソースごとに .dll プロジェクトをさまざまなソリューションにバインドする必要がありますか、それとも release.dll によって直接バインドする必要がありますか?
人々が SVN によってファイルを取得して dll ソースを再バインドするのを防ぐにはどうすればよいですか (グローバル アセンブリの問題など)。
概要を簡単に把握するために、できるだけ多くの .dll を使用する (機能ごとに分割する) のと、1 つの大きな .dll を使用するのとではどちらがよいでしょうか?
私はこのビジネスの初心者で、英語は母国語ではありません。
事前にありがとう、ハリー。
.NETのDLLについてのことは、それらが.NETWindows以前のプログラミングのDLLとはまったく似ていないということです。それらは単なるコードのコンテナです。
数年前に私もこれを説明した良い記事を読みました。これはかつて私も混乱させていたので、名前空間、アセンブリ、プロジェクト間の関係について話している、MSパターンと実践の人々の1人によって書かれたと私は信じていますおよび解決策（見つけた場合はリンクを投稿します）。
ソース管理の目的では、コードを保存し、エンドユーザーのマシンでコンパイルできるようにする方がよいと思います。コンパイルされたDLLをソース管理に入れることは、通常、サードパーティの依存関係に対して行うことです。
これはすべて私の経験からのものです-一部の専門家はより良いアドバイスを持っているかもしれません。
外部 dll を含む独自の NuGet フィードを設定することをお勧めします。NUGet フィードを共有フォルダーとしてセットアップできます (インストールは不要です)。これらのフィードは組織の内部にあり、アップグレードを完全に制御できます。
同じ NuGet パッケージを使用して、複数のプロジェクトで同じ dll を共有できます。
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
アプリケーションでdllを使用することは、どのdllを使用しているのかによって異なるため、「はい」または「いいえ」で答えられる質問ではないと思います。
したがって、ソリューションでサードパーティのdllをすでに使用している場合は、作成しているdllの代わりにコードを配置することがベストプラクティスになると思います。これにより、多くのdllがなくなり、コンパイラに多くのdllの参照がなくなります。同じように。
3層アーキテクチャは良い習慣だと思います。
GUI.dll
ビジネス.dll
データ アクセス.dll
デバッグ構成でデバッグ dll を参照し、リリース構成でリリース dll を参照するため、DLL 参照ではなくプロジェクト参照を好みます。
通常、コードを別のアセンブリに分割する必要があるのは、それを行う正当な理由がある場合です....
コードを 1 つの大きなプロジェクトに入れるのではなく、dll に入れる理由はたくさんあります。しかし、それを行う理由がない場合は、多くの dll を作成しないでください (名前空間ごとに 1 つの dll を作成する ppl を見たことがありますが、それらにはそれほど多くのクラスが含まれておらず、それらを分割する理由はありませんでした)。
もちろん、コードをdllに分割すると、dll aにクラスがあり、dll bにクラスがあり、それぞれが別のクラスへの参照を必要とするなど、いくつかの問題が発生する可能性があります。これは主にアプリケーションの設計上の問題です。