.NET 程序集的 LoadFile 和 LoadFrom 之间的区别?

发布于 2024-08-06 06:43:35 字数 571 浏览 5 评论 0原文

我正在查看 msdn 文档,但对于加载程序集时使用 LoadFileLoadFrom 之间的确切区别仍然有点困惑。有人可以提供一个例子或类比来更好地描述它。 MSDN 文档让我更加困惑。另外,ReflectionOnlyLoadFrom 是否与 LoadFrom 相同,只不过它仅在反射模式下加载程序集。

由于我的 .NET 经验不是最丰富的,因此以下是有关使用 LoadFile 的 MSDN 文档的一些问题:

1) LoadFile 检查具有相同标识但位于不同路径的程序集是什么意思?身份是什么(示例)?

2) 它指出 LoadFile 不会将文件加载到“LoadFrom Context”中,并且不会使用加载路径解析依赖项。这是什么意思,有人可以举个例子吗?

3) 最后,它指出 LoadFile 在这种有限的场景中很有用,因为 LoadFrom 无法加载具有相同标识但不同路径的程序集;它只会加载第一个这样的程序集,这再次让我想到同样的问题,程序集的身份是什么?

I was looking at the msdn documentation and I am still a little confused on what exactly is the difference between using LoadFile and LoadFrom when loading an assembly. Can someone provide an example or an analogy to better describe it. The MSDN documentation confused me more. Also, Is ReflectionOnlyLoadFrom the same as LoadFrom except that it loads the assembly only in reflection mode.

Since my .NET experience is not the greatest, here are some questions regarding the MSDN documentation using LoadFile:

1) What does it mean by LoadFile examines assemblies that have the same Identity, but are located in different paths? What is the identity (example)?

2) It states the LoadFile does not load files into the 'LoadFrom Context' and does not resolve dependencies using the load path. What does this mean, can someone provide an example?

3) Lastly, it states that LoadFile is useful in this limited scenario because LoadFrom cannot load assemblies that have the same identities but different paths; it will only load the first such assembly, which again brings me to the same question, what is the assemblies identity?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

女中豪杰 2024-08-13 06:43:35

这能澄清吗?

// path1 and path2 point to different copies of the same assembly on disk:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);

// These point to different assemblies now, so this is false
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

编辑:要回答您在修订后的问题中提出的问题,您一定要阅读Suzanne Cook 谈程序集身份

有很多规则控制程序集的加载方式,其中一些规则与它们如何解决依赖关系有关 - 如果您的 AssemblyA 依赖于 AssemblyB,.NET 应该在哪里查找 AssemblyB?在全局程序集缓存中,它找到 AssemblyA 的目录相同,还是完全在其他地方?此外,如果它找到该程序集的多个副本,它应该如何选择使用哪一个?

LoadFrom 有一组规则,而 LoadFile 有另一组规则。很难想象使用 LoadFile 的多种理由,但如果您需要在同一程序集的不同副本上使用反射,那么它就适合您。

Does this clear it up?

// path1 and path2 point to different copies of the same assembly on disk:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);

// These point to different assemblies now, so this is false
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);

Edit: to answer the questions you raised in your revised question, you definitely want to read Suzanne Cook on Assembly Identity.

There are a lot of rules that govern how assemblies are loaded, and some of them have to do with how they resolve dependencies - if your AssemblyA is dependent on AssemblyB, where should .NET look to find AssemblyB? In the Global Assembly Cache, the same directory it found AssemblyA, or somewhere else entirely? Furthermore, if it finds multiple copies of that assembly, how should it choose which one to use?

LoadFrom has one set of rules, while LoadFile has another set of rules. It is hard to imagine many reasons to use LoadFile, but if you needed to use reflection on different copies of the same assembly, it's there for you.

凉世弥音 2024-08-13 06:43:35

来自 Suzanne Cook 的博客

LoadFile 与 LoadFrom

小心 - 这些不一样
东西。

LoadFrom() 通过 Fusion 并可以重定向到另一个
装配在不同的路径但与
相同的身份(如果已经存在)
在 LoadFrom 上下文中加载。

LoadFile() 根本不通过 Fusion 绑定 - 加载程序只是运行
提前并准确加载*什么
来电者要求。它不使用
Load 或 LoadFrom
上下文。

所以,LoadFrom() 通常会给你什么
你要求,但不一定。
LoadFile() 适合那些真正的人,
真的想要所要求的。
(*但是,从 v2 开始,策略将
应用于 LoadFrom() 和
LoadFile(),所以 LoadFile() 不会
必然是原来的样子
要求。另外,从 v2 开始,如果
其身份的程序集位于
GAC,将使用GAC副本
反而。使用 ReflectionOnlyLoadFrom()
准确加载您想要的内容 - 但是,
请注意,程序集以这种方式加载
无法执行。)

LoadFile() 有一个问题。自从它
不使用绑定上下文,它的
依赖关系不会自动产生
在其目录中找到。如果他们不是
在加载上下文中可用,您
必须订阅
AssemblyResolve 事件以便绑定
给他们。

请参阅此处

另请参阅选择绑定上下文一文在同一个博客上。

From Suzanne Cook's blog:

LoadFile vs. LoadFrom

Be careful - these aren't the same
thing.

LoadFrom() goes through Fusion and can be redirected to another
assembly at a different path but with
that same identity if one is already
loaded in the LoadFrom context.

LoadFile() doesn't bind through Fusion at all - the loader just goes
ahead and loads exactly* what the
caller requested. It doesn't use
either the Load or the LoadFrom
context.

So, LoadFrom() usually gives you what
you asked for, but not necessarily.
LoadFile() is for those who really,
really want exactly what is requested.
(*However, starting in v2, policy will
be applied to both LoadFrom() and
LoadFile(), so LoadFile() won't
necessarily be exactly what was
requested. Also, starting in v2, if an
assembly with its identity is in the
GAC, the GAC copy will be used
instead. Use ReflectionOnlyLoadFrom()
to load exactly what you want - but,
note that assemblies loaded that way
can't be executed.)

LoadFile() has a catch. Since it
doesn't use a binding context, its
dependencies aren't automatically
found in its directory. If they aren't
available in the Load context, you
would have to subscribe to the
AssemblyResolve event in order to bind
to them.

See here.

Also see Choosing a Binding Context article on the same blog.

遗失的美好 2024-08-13 06:43:35

经过一番苦思冥想,今天下午我自己发现了一个不同之处。

我想在运行时加载一个 DLL,而该 DLL 位于另一个目录中。该 DLL 有其自己的依赖项 (DLL),它们也位于同一目录中。

LoadFile():加载特定的DLL,但不加载依赖项。因此,当从 DLL 内对其他 DLL 之一进行第一次调用时,它会抛出 FileNotFoundException。

LoadFrom():加载我指定的 DLL 以及该目录中的所有依赖项。

After a lot of head-scratching I've discovered a difference myself this afternoon.

I wanted to load a DLL at runtime, and the DLL lived in another directory. That DLL had its own dependencies (DLLs) which also lived in that same directory.

LoadFile(): Loaded the specific DLL, but not the dependencies. So when the first call was made from within the DLL to one of those other DLLs it threw a FileNotFoundException.

LoadFrom(): Loaded the DLL that I specified and also all the dependencies that lived in that directory.

著墨染雨君画夕 2024-08-13 06:43:35

注意:如果使用 8.3 路径加载一个程序集,然后从非 8.3 路径加载,则它们将被视为不同的程序集,即使它们是相同的物理 DLL。

Note: If one assembly is loaded using an 8.3 path, and then from a non-8.3 path, they will be seen as different assemblies, even though they are the same physical DLL.

入怼 2024-08-13 06:43:35

.NET 有不同的加载上下文。 Suzanne Cook 在这里写了关于它们的文章: https:/ /learn.microsoft.com/en-us/archive/blogs/suzcook/choosing-a-binding-context

这是 .NET 隔离引用不混淆的方式。

.NET has different load context. Suzanne Cook wrote about them here: https://learn.microsoft.com/en-us/archive/blogs/suzcook/choosing-a-binding-context

This is the way .NET quarantines that references are not mixed up.

惜醉颜 2024-08-13 06:43:35

就我而言,我只需删除位于 C:\Windows\Microsoft.NET\Framework\[asp 版本]\Temporary ASP.NET Files 的 ASP 应用程序缓存即可。它会在站点首次运行时重建。请务必先停止 IIS。

希望这对某人有帮助,就像对我一样。

In my case, I just had to simply delete the ASP application cache located @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. It is rebuilt when the site is first run. Be sure to stop IIS first.

Hope this helps someone like it did for me.

夜灵血窟げ 2024-08-13 06:43:35

我注意到的一个区别是:

Assembly.LoadFile - 在具有有限用户权限的不同 AppDomain 中加载程序集(不同原理)。无法执行序列化/反序列化等操作。

Assembly.LoadFrom - 使用相同的用户权限(相同的原理)在同一 AppDomain 中加载程序集。

one difference that i noticed is:

Assembly.LoadFile - Loads assembly in different AppDomain with limited user rights (diffrence principel). operations like serilization/deserilization could not be performed.

Assembly.LoadFrom- Loads assembly in same AppDomain with same user rights (same principel).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文