C# 静态链接优势

Static linking advantages

提问by J Cooper

I recently read a question on here about static and dynamic linking, which reminded me of some questions I've had about it. From that post, I can see what the technical difference is (including object file contents directly instead of merely pointing to it), but I'd like to know a bit more about the pros/cons of doing so.

我最近在这里阅读了一个关于静态和动态链接的问题，这让我想起了一些关于它的问题。从那篇文章中，我可以看到技术差异是什么（直接包括目标文件内容，而不仅仅是指向它），但我想更多地了解这样做的利弊。

A while ago, a friend of mine who's been programming several years was lamenting that C# isn't statically linked and saying that that was the feature he desired most for a future version. Unfortunately I'm a novice and don't really understand this statement.

不久前，我的一个编程多年的朋友感叹 C# 不是静态链接的，并说这是他未来版本最想要的功能。不幸的是，我是一个新手，并不真正理解这个说法。

Thanks for any enlightenment!

感谢您的启发！

采纳答案by Tamas Czinege

I am not sure if static linking is a really good idea in C# to be honest, for a million reasons. One reason is that, as opposed to languages like C or C++, C# has the concept of assemblies, which are basically executable files or DLLs.

老实说，出于一百万个原因，我不确定静态链接是否是 C# 中的一个好主意。一个原因是，与 C 或 C++ 等语言不同，C# 具有程序集的概念，它基本上是可执行文件或 DLL。

Now if you want link things statically in .NET, you either

现在，如果您想在 .NET 中静态链接事物，您可以

• Merge classes from multiple assemblies into a single assembly. That would break a lot of things, like the "internal" access modifier.
• Have more than one assembly in the same executable. That would render the whole concept of assemblies useless though, and would require to redesign the approach to reflection in the .NET Framework.

• 将多个程序集中的类合并到一个程序集中。这会破坏很多东西，比如“内部”访问修饰符。
• 在同一个可执行文件中有多个程序集。但是，这会使程序集的整个概念变得毫无用处，并且需要重新设计 .NET Framework 中的反射方法。

I'm sure there is a clever way to avoid these problems, but I don't quite see the point of statically linking in a managed environment like .NET or Java. I mean, statically linking indeed improves performance, but not THAT much. And we don't use managed languages for their execution speed anyway.

我确信有一种聪明的方法可以避免这些问题，但我不太明白在 .NET 或 Java 等托管环境中静态链接的意义。我的意思是，静态链接确实提高了性能，但不是那么多。无论如何，我们不使用托管语言来提高执行速度。

Another issue is DLL hell, but in .NET, that's pretty much a solved issue anyway.

另一个问题是 DLL 地狱，但在 .NET 中，这几乎是一个已解决的问题。

回答by Fernando Miguélez

A statically executable contains all the objects that it needs so no external DLL will be called when executed. The advantaje is that is is portable accross a lot of platforms no matter what version of DLLs have been installed on that system. The BIG disadvantage is that you are probable wasting disk space since you are including in your executable code that is already present in system/external DLLs. Moreover I think, but I'm not very sure, that DLLs are loaded in main memory only once, no matter how many executables are using them, but if you link statically the library objects inside your executable you load the same code twice (one for the DLL used by the rest of the programs and one for your executable). On the other hand this could be an advantage instead a disatvadvantage, since the executable contains only the objects of the external libraries that it needs, not the whole library. A DLL is loaded in memory as a whole when an application needs it.

静态可执行文件包含它需要的所有对象，因此在执行时不会调用外部 DLL。优点是它可以跨许多平台移植，无论该系统上安装了什么版本的 DLL。最大的缺点是您可能会浪费磁盘空间，因为您将包含在系统/外部 DLL 中已经存在的可执行代码中。此外，我认为，但我不太确定，无论有多少可执行文件正在使用它们，DLL 只会在主内存中加载一次，但是如果您静态链接可执行文件中的库对象，您将两次加载相同的代码（一个用于其余程序使用的 DLL，一个用于可执行文件）。另一方面，这可能是一个优势，而不是一个劣势，因为可执行文件只包含它需要的外部库的对象，而不是整个库。当应用程序需要时，DLL 会作为一个整体加载到内存中。

Static linking is ideal to compile small apps that you want to carry from one system to another as a small tool. I.e. it was really useful for me to have a statically compiled version of tcpdump when it was not included in every Linux distro. It was bound to work on every Linux no matter what version of Kernel, glibc or other system libraries had. Perhaps it has not so much sense in Windows world since the platforms are much more homogeneus. If you compile for Windows XP / NET vX.X it will work across a lot of computers. If you compile something for Debian X.X it will surely not work on older/newer Debians or other distros such as Redhat.

静态链接非常适合编译您希望作为小工具从一个系统携带到另一个系统的小型应用程序。也就是说，当每个 Linux 发行版中都没有包含 tcpdump 的静态编译版本时，它对我来说真的很有用。无论内核、glibc 或其他系统库的版本是什么，它都必须在每个 Linux 上运行。也许它在 Windows 世界中没有多大意义，因为平台更加同质。如果您为 Windows XP / NET vX.X 编译，它将在许多计算机上运行。如果你为 Debian XX 编译一些东西，它肯定不能在旧的/新的 Debian 或其他发行版（如 Redhat）上运行。

This threadcan also solve your questions.

这个线程也可以解决你的问题。

回答by Fernando Miguélez

The advantage of static linking is that it removes external dependency on libraries - i.e. the behaviour of the library you're using is never going to change because someone changed the libraryon the disk. That's also one of the disadvantages of static linking; if the OS changes and a new version of the library is needed to work with it properly, you have to provide an upgraded version of your binary. Similarly if a bugfix is added to the library, you don't automatically get that bug fix if you've statically linked.

静态链接的优点是它消除了对库的外部依赖——即您使用的库的行为永远不会因为有人更改了磁盘上的库而改变。这也是静态链接的缺点之一；如果操作系统发生变化并且需要新版本的库才能正常使用，则必须提供二进制文件的升级版本。类似地，如果将错误修正添加到库中，如果您进行了静态链接，则不会自动获得该错误修正。

Most (in fact, probably all these days) operating systems can load one copy of a dynamic library for multiple processes, which is why on UNIX they're called shared objects.

大多数（事实上，可能所有这些天）操作系统都可以为多个进程加载一个动态库的副本，这就是为什么在 UNIX 上它们被称为共享对象。

回答by Jeppe

There is a good example of the difference between static vs dynamic linking. If you check out the InkScape project you will find InkscapePortableand InkScape. InkscapePortable will run off a USB stick. InkScape will not.

有一个很好的例子来说明静态链接和动态链接之间的区别。如果您查看 InkScape 项目，您会发现InkscapePortable和 InkScape。InkscapePortable 将通过 USB 记忆棒运行。InkScape 不会。

回答by Eonil

All the required stuffs are packaged into an executable. So,

所有需要的东西都打包成一个可执行文件。所以，

• You don't need to install any other stuffs. Just copy and run. Or run where it is. No installer, no caveat, no weird error due to wrong DLL version. That's all.
• Also your users can enjoy this simplicity. This is usually a lot more important. Nobody welcomes installing dependencies. Especially if it's huge like .NET framework.

• 您不需要安装任何其他东西。只需复制并运行。或者跑到哪里去。没有安装程序，没有警告，没有由于错误的 DLL 版本而导致的奇怪错误。就这样。
• 您的用户也可以享受这种简单性。这通常要重要得多。没有人欢迎安装依赖项。特别是如果它像 .NET 框架一样庞大。

Of course size of executable file will increase but it should be smaller than bunch of silly graphics files.

当然可执行文件的大小会增加，但它应该比一堆愚蠢的图形文件小。