静的リンクの利点は、ライブラリへの外部依存が取り除かれることです。つまり、使用しているライブラリの動作は、ディスク上のライブラリが変更されたために変更されることはありません。これは、静的リンクの欠点の 1 つでもあります。OS が変更され、適切に動作するために新しいバージョンのライブラリが必要になった場合は、アップグレードされたバージョンのバイナリを提供する必要があります。同様に、バグ修正がライブラリに追加された場合、静的にリンクした場合、そのバグ修正は自動的には取得されません。
ほとんどの (実際、最近ではおそらく) オペレーティング システムは、複数のプロセスに対して動的ライブラリの 1 つのコピーを読み込むことができます。そのため、UNIX では共有オブジェクトと呼ばれます。
静的実行可能ファイルには必要なすべてのオブジェクトが含まれているため、実行時に外部 DLL が呼び出されることはありません。利点は、そのシステムにインストールされている DLL のバージョンに関係なく、多くのプラットフォーム間で移植可能であることです。大きな欠点は、システム/外部 DLL に既に存在する実行可能コードに含めるため、ディスク領域を浪費する可能性があることです。さらに、実行可能ファイルの数に関係なく、DLL がメイン メモリに読み込まれるのは 1 回だけだと思いますが、よくわかりませんが、実行可能ファイル内のライブラリ オブジェクトを静的にリンクすると、同じコードが 2 回読み込まれます (1 つの残りのプログラムで使用される DLL 用と実行可能ファイル用)。一方、これは欠点ではなく利点である可能性があります。実行可能ファイルには、ライブラリ全体ではなく、必要な外部ライブラリのオブジェクトのみが含まれているためです。DLL は、アプリケーションが必要とするときに全体としてメモリに読み込まれます。
静的リンクは、小さなツールとして 1 つのシステムから別のシステムに持ち運びたい小さなアプリをコンパイルするのに理想的です。つまり、すべての Linux ディストリビューションに含まれていない tcpdump の静的にコンパイルされたバージョンを持っていることは、私にとって本当に役に立ちました。カーネル、glibc、その他のシステム ライブラリのバージョンに関係なく、すべての Linux で動作するはずでした。Windows の世界では、プラットフォームがはるかに均一であるため、おそらくあまり意味がありません。Windows XP / NET vX.X 用にコンパイルすると、多くのコンピューターで動作します。Debian XX 用に何かをコンパイルすると、古い/新しい Debian や Redhat などの他のディストリビューションでは確実に動作しません。
このスレッドもあなたの疑問を解決します。
正直なところ、静的リンクが C# で本当に良いアイデアであるかどうかはわかりません。理由はたくさんあります。理由の 1 つは、C や C++ などの言語とは異なり、C# にはアセンブリの概念があり、基本的に実行可能ファイルまたは DLL であるためです。
.NET で静的にリンクする場合は、次のいずれかを行います。
これらの問題を回避する賢い方法があることは確かですが、.NET や Java などの管理された環境で静的にリンクする意味がよくわかりません。つまり、静的リンクは確かにパフォーマンスを向上させますが、それほどではありません。とにかく、実行速度のためにマネージ言語を使用していません。
もう 1 つの問題は DLL 地獄ですが、.NET では、とにかくほとんど解決済みの問題です。
静的リンクと動的リンクの違いの良い例があります。InkScape プロジェクトを調べると、InkscapePortableと InkScape が見つかります。InkscapePortable は USB スティックから実行されます。InkScape はそうしません。