我的目的是共享的DLL我的应用程序之间，这样，例如，如果我有2个应用程序加载一个20MB的DLL，比使用200MB的内存，而不是一个进程，另一个为200MB过，其中一人将受益于分享和只使用180MB的内存。 我的问题是有记忆的定义，请继续阅读。

我已经创建了一个参考2 .NET C＃应用程序并运行code FRM的一个大的DLL（20MB），它位于GAC。 随着.NET内存分析器，我可以看到使用了第二个进程确实在实际的物理内存比开始第一次（尽管它们是相同的）一个显著降低，这是位于第一的共享内存下的dll处理。 然而，随着性能监视器检查内存计数器，当我看到这两个应用程序的增加（与DLL的大小相关）单独运行的每一个时，它们增加了同样大小的虚拟内存。

这引出了一个问题：什么点中有共享（内存经济WISE）的动态链接库，如果只是物理内存受益于它，但虚拟内存，它是从应用的角度来看，是重要的事情

编辑：感谢您​​的答案。根据答案，我想强调的是，我明白共享的DLL在内存中保存的物理内存的好处。更precise的问题，我要问的是： 有没有任何好处，应用智慧（非系统明智的），从DLL的在.NET应用程序之间共享的方式是什么？ 我问这个的原因是因为我在乎的虚拟内存，我的应用程序正在使用（计）的量。

RAM事项。虚拟内存没有任何费用，它是虚拟的。多个进程共享同一内存是一个大问题。任何Windows程序对KERNEL32.DLL的依赖。但是，只有的一个的其code在RAM中的副本。

以在管理程序利用进程共享code需要ngen.exe运行，使它们都得到完全相同的机器code。没有什么能如果code是刚刚在时间编译共享。

My intention is the share dll's between my applications, such that if for example I have 2 applications that load a 20MB dll, than instead of one process using 200MB memory and another with 200MB too, one of them will benefit from sharing and use only 180MB memory. My problem is with the definition of memory, please keep reading.

I've created 2 .net c# applications that reference and run code frm a large dll (20MB) which is located in the GAC. With .NET Memory Profiler I could see that indeed the actual physical memory that was used by the second process was significantly lower than the one that was started first (although they are identical) and that the dll was located under the shared memory of the first process. Yet, when checking memory counters with perfmon I saw that the virtual memory of both applications increases (in correlation with the size of the dll) by the same size they increase when running each one alone.

This leads to the question: What point there is in sharing (memory-economic wise) dll's if only physical memory benefits from it but the virtual memory, which is from the application point of view, the thing that matters.

Edit: Thanks for the answers. Based on the answers, I want to emphasize that I understand the benefit of sharing dll's in memory to save physical ram. The more precise question I should be asking is: Is there any benefit, application wise (not system wise), from the way dll's are shared between applications in .net? The reason I'm asking this is because I do care about the amount of virtual memory that my applications are using (in total).

RAM matters. Virtual memory doesn't cost anything, it is virtual. Multiple processes sharing the same RAM is a Big Deal. Any Windows process has a dependency on kernel32.dll. But there's only one copy of its code in RAM.

Taking advantage of processes sharing code in a managed program requires running ngen.exe so that they all get the exact same machine code. Nothing can be shared if the code is just-in-time compiled.