关于Assembly.LoadFrom和Assembly.LoadFile的区别

区别:

1、Assembly.LoadFile只载入相应的dll文件,比如Assembly.LoadFile("a.dll"),则载入a.dll,假如a.dll中引用了b.dll的话,b.dll并不会被载入。

Assembly.LoadFrom则不一样,它会载入dll文件及其引用的其他dll,比如上面的例子,b.dll也会被载入。

2、用Assembly.LoadFrom载入一个Assembly时,会先检查前面是否已经载入过相同名字的Assembly,比如a.dll有两个版本(版本1在目录1下,版本2放在目录2下),程序一开始时载入了版本1,当使用Assembly.LoadFrom("2\\a.dll")载入版本2
时,不能载入,而是返回版本1。

Assembly.LoadFile的话则不会做这样的检查,比如上面的例子换成Assembly.LoadFile的话,则能正确载入版本2。

时间: 2024-11-17 20:43:54

关于Assembly.LoadFrom和Assembly.LoadFile的区别的相关文章

Assembly.LoadFrom()和Assembly.LoadFile()的区别

System.Reflection.Assembly类有两个静态方法:Assembly.Load(string assemblyname)和Assembly.LoadFrom(string filename) .通常用这两个方法把程序集加载到应用程序域中. 如果你希望加载的程序集超出了CLR的预定探查范围,你可以用 Assembly.LoadFrom直接从一个文件位置加载程序集.Assembly.LoadFrom()和Assembly.LoadFile(),两者的主要区别有两点: 一:Assem

Assembly.Load()方法,Assembly.LoadFrom()方法,Assembly.LoadFile()方法的区别!

参考: http://www.cnblogs.com/benwu/archive/2009/10/24/1589096.html http://www.cnblogs.com/xuefeng1982/archive/2009/11/09/1598956.html 今天总算弄明白了Assembly.LoadFrom 与Assembly.Load 与 Assembly.LoadFile的一些区别, 以前只是用Assembly.Load来生成实例,现在遇到一个问题,就是从应用程序中来创建窗体, 网上找

为C# as 类型转换及Assembly.LoadFrom埋坑!

背景: 不久前,我发布了一个调试工具:发布:.NET开发人员必备的可视化调试工具(你值的拥有) 效果是这样的: 之后,有小部分用户反映,工具用不了(没反应或有异常)~~~ 然后,建议小部分用户换个电脑环境试试,有些就好了~~~ 于是,我假定是VS环境下的 Microsoft.VisualStudio.DebuggerVisualizers.dll 的版本不一致引发的. 因此,一般我都建议用户自己下载源码,重新引用去编绎一下!!! 由于该工具一直在CSDN论坛的VB.NET版块置顶着. 考虑到受众

C#反射之Assembly.Load,Assembly.LoadFile 与 Assembly.LoadFrom方法介绍

一些关于C#反射的知识,估计也就最多达到使用API的程度,至于要深入了解,以现在的水平估计很难做到,所以下面此篇文章,以作为一个阶段的总结. 对于反射的总结,我想从以下几个方面展开,首先是反射程序集,模块,类的成员以及成员的一些信息:接下来就是动态调用类的成员方法:第三个方面就动态产生程序集,模块和类以及类的成员.好了,现在就让我们从反射各种信息开始吧 在C#中,我们要使用反射,首先要搞清楚以下命名空间中几个类的关系: System.Reflection命名空间 (1)   AppDomain:

Assembly.LoadFrom加载程序集类型转换失败解决方法

为了让我的wcf模块框架支持自定义通道上下文,对代码又进行了一次小型的重构,测试时发现类型转换的错误,最后发现是loadfrom引起的.如果向 loadfrom 上下文中加载了一个程序集,则将激活 loadfromcontext 托管调试助手 (mda).因为默认时加载程序集是在defaul上下文的,所以就算是同一个程序集里,因上下文不同,类型也不同了,所以转换失败.最后用assembly.loadfile来解决了此问题. 假设: a.dll 中有一个接口 interface ab.dll 中有

配置到 Framework GAC(Global Assembly Cache) Assembly

配置到 Framework 通常有两种方法,一种是直接把它放到GAC(Global Assembly Cache作用是可以存放一些有很多程序都要用到的公共Assembly)中 :另一种是把它们放到具体的程序目录下. 要放到GAC里面,简单的方法就是直接把卫星配件拖放到"Windows/assembly"目录下,也可以使用Microsoft提供的工具gacutil,使用如下命令: gacutil /i:LocalizerRes.zh-CHS.resources.dll 如果不放到GAC中

Lua dofile loadfile loadstring 区别

dofile,把它当作 Lua 运行代码的 chunk 的一种原始的操作. 1. dofile 实际上是一个辅助的函数.真正完成功能的函数是 loadfile: 2.与 dofile 不同的是 loadfile 编译代码成中间码并且返回编译后的 chunk 作为一个函数,而不执行代码: 3. loadfile 不会抛出错误信息而是返回错误码. 将TestMain中的Print.lua改成otherPrint.lua(该lua文件不存在),结果如上,loadfile返回错误码和错误信息,dofil

Assembly中Load, LoadFrom, LoadFile以及AppDomain, Activator类中相应函数的区别

Assembly和AppDomain的一些关于动态加载程序集的函数有些令人头疼,但细细研究后还是可以将他们区分的. 这些函数大致可以分为四类: 第一类:加载到Load Context内 Load Context: Load Context是所有动态加载程序集首选应该被加载到的地方. 它只能加载在AppDomain信息中的ApplicationBase目录以及附带的PrivateBinPath目录内的程序集(关于这两个目录:可以参考另一篇文章:http://www.cnblogs.com/mgen

重温.NET下Assembly的加载过程

原文:重温.NET下Assembly的加载过程 最近在工作中牵涉到了.NET下的一个古老的问题:Assembly的加载过程.虽然网上有很多文章介绍这部分内容,很多文章也是很久以前就已经出现了,但阅读之后发现,并没能解决我的问题,有些点写的不是特别详细,让人看完之后感觉还是云里雾里.最后,我决定重新复习一下这个经典而古老的问题,并将所得总结于此,然后会有一个实例对这个问题进行演示,希望能够帮助到大家. .NET下Assembly的加载过程 .NET下Assembly的加载,最主要的一步就是确定As