Assembly.LoadFrom Method (String, Evidence, Byte, AssemblyHashAlgorithm)
Assembly: mscorlib (in mscorlib.dll)
public static Assembly LoadFrom ( string assemblyFile, Evidence securityEvidence, byte hashValue, AssemblyHashAlgorithm hashAlgorithm )
public static Assembly LoadFrom ( String assemblyFile, Evidence securityEvidence, byte hashValue, AssemblyHashAlgorithm hashAlgorithm )
public static function LoadFrom ( assemblyFile : String, securityEvidence : Evidence, hashValue : byte, hashAlgorithm : AssemblyHashAlgorithm ) : Assembly
The name or path of the file that contains the manifest of the assembly.
Evidence for loading the assembly.
The value of the computed hash code.
The hash algorithm used for hashing files and for generating the strong name.
Return ValueThe loaded assembly.
assemblyFile is a null reference (Nothing in Visual Basic).
assemblyFile is not found, or the module you are trying to load does not specify a filename extension.
A file that was found could not be loaded.
The securityEvidence is not ambiguous and is determined to be invalid.
assemblyFile is not a valid assembly.
Version 2.0 or later of the common language runtime is currently loaded and assemblyFile was compiled with a later version.
A codebase that does not start with "file://" was specified without the required WebPermission.
The assemblyFile parameter is an empty string ("").
The assembly name is longer than MAX_PATH characters.
The assemblyFile parameter must refer to a URI without escape characters. This method supplies escape characters for all invalid characters in the URI.
File transfer protocol (FTP) is not supported. If the URI supplied for assemblyFile is an FTP address, the assembly is not loaded. No exception is thrown.
assemblyFile is relative to the current directory, and the assembly is loaded into the domain of the caller.
Assemblies can be loaded into one of three contexts, or can be loaded without context:
The load context contains assemblies found by probing: in the GAC, in a host assembly store if the runtime is hosted, or in the ApplicationBase and PrivateBinPath of the application domain. Most overloads of the Load method load assemblies into this context.
The load-from context contains assemblies for which the user provided a path not included in the directories searched by probing. LoadFrom, CreateInstanceFrom, and ExecuteAssembly are examples of methods that load by path.
If the user generated or found the assembly, it is not in any context. This applies to assemblies loaded using overloads of the Load method that specify a byte array containing an assembly, and to transient dynamic assemblies created with reflection emit and not saved to disk.
The load-from context allows an assembly to be loaded from a path not included in probing, and yet allows dependencies on that path to be found and loaded because the path information is maintained by the context.
The LoadFrom method has the following disadvantages. Consider using Load instead.
If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified.
If an assembly is loaded with LoadFrom, and later an assembly in the load context attempts to load same the assembly by display name, the load attempt fails. This can occur when an assembly is deserialized.
If an assembly is loaded with LoadFrom, and the probing path includes an assembly with the same identity but a different location, an InvalidCastException, MissingMethodException, or other unexpected behavior can occur.
If a native image exists for assemblyFile, it is not used. The assembly cannot be loaded as domain neutral.
In the .NET Framework version 1.0 and 1.1, policy is not applied.
Whether certain permissions are granted or not granted to an assembly is based on evidence. The rules for assembly and security evidence merging are as follows:
When you use a LoadFrom method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the LoadFrom method supersede pieces of evidence supplied by the loader.
If you call this method more than once on the same assembly but with a different evidence specified, the common language runtime does not throw a FileLoadException because the equality and integrity of the different evidence specifications cannot be determined. The evidence that first succeeds is the evidence that is used.
When you use a LoadFrom method with a Byte parameter to load a common object file format (COFF) image, evidence is combined. Zone, Url and Site are inherited from the calling assembly, and Hash and StrongName are taken from the COFF assembly.
When you use a LoadFrom method with a Byte parameter and Evidence to load a COFF image, only the supplied evidence is used. Evidence of the calling assembly and evidence of the COFF image is ignored.
- SecurityPermission to load an assembly with evidence. Associated enumeration: SecurityPermissionFlag.ControlEvidence.
- FileIOPermission for reading a URI that begins with "file://". Associated enumeration: FileIOPermissionAccess.Read
- WebPermission for reading a URI that does not begin with "file://".
Windows 98, Windows Server 2000 SP4, Windows Millennium Edition, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter EditionThe Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.