1 个 DLL 中的私有并行程序集 - 与通常的 DLL 相同吗？
我正在研究 Microsoft Windows 中的并行程序集和隔离应用程序解决方案。
文档说：
私有程序集是这样的程序集： 与应用程序一起部署并且是 可供独家使用 该应用程序。
和
私有程序集必须设计为 与其他版本并行工作 系统上的程序集。
但是，私有程序集的部署过程只是将程序集复制到应用程序的文件夹（或具有程序集名称的子文件夹）中。因此，应用程序不能使用多个版本的私有程序集。因为如果您放置另一个版本的私有程序集 - 它会覆盖旧版本。
有人可以向我解释一下吗？
如果确实如此，那么与具有重定向功能的普通 DLL 相比，此类程序集有何优势？它们对我来说似乎非常相似，并且清单似乎甚至没有在这里使用。
I'm looking at Side-by-Side assemblies and isolated application solution in Microsoft Windows.
Documentation says:
A private assembly is an assembly that
is deployed with an application and is
available for the exclusive use of
that application.
and
Private assemblies must be designed to
work side-by-side with other versions
of the assembly on the system.
However, the deployment process for private assembly is just copying assebly into application's folder (or subfolder with assembly's name). Thus, application can not use more than one version of private assembly. Because if you put another version of private assembly - it'll overwrite old version.
Can someone explain this to me?
If this is indeed so - then what are advantages of such assemblies over usual DLLs with redirection? They seems pretty the same to me and manifest seems not even be used here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用私有 SxS 程序集来部署 dll 实际上只是一种使事情更频繁失败的复杂方法。
不过，也有一些优点：
但是，您可以使用
要使用激活上下文 API，您需要：
认识到这不能用于静态绑定资源，因为这些资源始终加载在操作系统加载程序生成的上下文中。
创建一些应用程序清单文件，描述您希望随应用程序一起加载的依赖程序集 - 在外部或嵌入为具有资源 ID 的 RT_MANIFEST 资源 > 16.
填充ACTCTX 包含清单所在位置详细信息的结构，并确保 lpAssemblyDirectory 指向保存特定版本的私有 SxS 程序集的目录。调用 CreateActCtx 创建激活上下文对象。
当需要加载特定版本的 dll 时，使用 ActivateActCtx，然后对 dll 的简单名称调用 LoadLibrary。在调用后停用它，因为加载 dll 后，激活上下文不再需要处于活动状态 - 直到 & 您再次调用需要搜索激活上下文的 API 函数 - 例如，创建 dll 中托管的类的窗口，或创建免注册 com 对象。
加载 dll 时，系统将在提供的 lpAssemblyDirectory 中搜索 dll 及其可能具有的任何依赖程序集。
Using private SxS assemblies to deploy dlls is really just a complicated way of making things fail more often.
There are some advantages however:
However, you can create your own activation contexts at runtime using the Activation Context API with base folders you specify, that will then be searched for private SxS assemblies. You can use this technique to dynamically load optional assemblies, or different versions of assemblies to implement some kind of plugin api if necessary.
To use the Activation Context API you need to:
Realize that this cannot be used for statically bound resources as those are always loaded in a context generated by the OS loader.
create some application manifest files describing the dependent assemblies you want to optionally load that you ship with your application - externally, or embedded as RT_MANIFEST resources with resource IDs > 16.
Populate an ACTCTX structure with the details of where the manifest is located, and ensure that lpAssemblyDirectory points to a directory holding a specific version of a private SxS assembly. Call CreateActCtx to create an activation context object.
When it comes time to load a specific version of the dll, activate the appropriate activation context using ActivateActCtx, then call LoadLibrary on the simple name of the dll. Deactivate it after the call as, with the dll loaded, the activation context is no longer required to be active - until & unless you make another call to an API function that will need to search the activation context - e.g. create a window of a class hosted in the dll, or create a registration free com object.
The system will - while loading the dll - search the provided lpAssemblyDirectory for the dll AND any dependent assemblies it may have.
嗯，每个 EXE 都有自己的私有 DLL。这里没有覆盖，您可以将每个 EXE 放在其自己的安装目录中。他们可以根据设计拥有不同版本的 DLL，DLL Hell 是不存在的。除此之外，这些 DLL 可能会接触文件系统或注册表的其他部分，并互相踩踏。提到“必须设计为并行工作”。这很少是很难实现的。
Well, each EXE will have its own private DLL. No overwriting here, you'd put each EXE in its own install directory. They can have different versions of the DLL by design, DLL Hell is non-existent. Other than that those DLLs might touch other parts of the file system or the registry and step on each other toes doing that. The reference to "must be designed to work side-by-side". This is rarely hard to achieve.