Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols and specifying the source for the security context. The assembly is loaded into the application domain of the caller.

Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols and evidence for the assembly. The assembly is loaded into the application domain of the caller.

Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols for the assembly. The assembly is loaded into the application domain of the caller.

Remarks

FileLoadException is thrown if assemblyRef specifies the full assembly name and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name. Starting with .NET Framework 4, because execution of code in remote assemblies is disabled by default, a FileLoadException is also thrown if assemblyRef specifies a remote assembly. To enable execution of code loaded from remote locations, you can use the <loadFromRemoteSources> configuration element.

Note

Do not use an AssemblyName with only the CodeBase property set. The CodeBase property does not supply any elements of the assembly identity (such as name or version), so loading does not occur according to load-by-identity rules, as you would expect from the Load method. Instead, the assembly is loaded using load-from rules. For information about the disadvantages of using the load-from context, see the Assembly.LoadFrom method overload or Best Practices for Assembly Loading.

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 Load method with no Evidence parameter, the assembly is loaded with the evidence that the loader supplies.

When you use a Load method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the Load method supersede pieces of evidence supplied by the loader.

When you use a Load method overload with a Byte[] parameter to load a common object file format (COFF) image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases.

Note

In the .NET Framework version 1.0 and in version 1.1 without SP1, when you use a Load method overload with a Byte[] parameter to load a 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 Load 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.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

Note

If both the AssemblyName.Name property and the AssemblyName.CodeBase property are set, the first attempt to load the assembly uses the display name (including version, culture, and so on, as returned by the Assembly.FullName property). If the file is not found, CodeBase is used to search for the assembly. If the assembly is found using CodeBase, the display name is matched against the assembly. If the match fails, a FileLoadException is thrown.

Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols and specifying the source for the security context. The assembly is loaded into the application domain of the caller.

The value of securityContextSource is not one of the enumeration values.

Remarks

The assembly is loaded into the application domain of the caller using the specified source for the security context. If rawSymbolStore was specified, the raw bytes that represent the symbols for the assembly are also loaded.

Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols and evidence for the assembly. The assembly is loaded into the application domain of the caller.

[System.Obsolete]
[System.Obsolete("This method is obsolete and will be removed in a future release of the .NET Framework. Please use an overload of Load which does not take an Evidence parameter. See http://go.microsoft.com/fwlink/?LinkID=155570 for more information.")]
public static System.Reflection.Assembly Load (byte[] rawAssembly, byte[] rawSymbolStore, System.Security.Policy.Evidence securityEvidence);

securityEvidence is not null. By default, legacy CAS policy is not enabled in the .NET Framework 4; when it is not enabled, securityEvidence must be null.

Remarks

The assembly is loaded into the domain of the caller using the supplied evidence. The raw bytes representing the symbols for the assembly are also loaded.

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 Load method with no Evidence parameter, the assembly is loaded with the evidence that the loader supplies.

When you use a Load method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the Load method supersede pieces of evidence supplied by the loader.

When you use a Load method overload with a Byte[] parameter to load a COFF image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases.

Note

In the .NET Framework version 1.0 and in version 1.1 without SP1, when you use a Load method overload with a Byte[] parameter to load a 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 Load 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 are ignored.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

If you call the [], Byte<xref:System.Reflection.Assembly.Load%2A> 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.

Note that this method overload always creates a new Assembly object with its own mapping.

[System.Obsolete]
[System.Obsolete("This method is obsolete and will be removed in a future release of the .NET Framework. Please use an overload of Load which does not take an Evidence parameter. See http://go.microsoft.com/fwlink/?LinkID=155570 for more information.")]
public static System.Reflection.Assembly Load (string assemblyString, System.Security.Policy.Evidence assemblySecurity);

Remarks

FileLoadException is thrown if assemblyString specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name.

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 Load method with no Evidence parameter, the assembly is loaded with the evidence that the loader supplies.

When you use a Load method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the Load method supersede pieces of evidence supplied by the loader.

When you use a Load method overload with a Byte[] parameter to load a common object file format (COFF) image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases.

Note

In the .NET Framework version 1.0 and in version 1.1 without SP1, when you use a Load method overload with a Byte[] parameter to load a 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 Load 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.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

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.

In the .NET Framework version 2.0, processor architecture is added to assembly identity, and can be specified as part of assembly name strings. For example, "ProcessorArchitecture=msil". However, the recommended way to specify an assembly name is to create an AssemblyName object and pass it to an appropriate overload of the Load method. See AssemblyName.ProcessorArchitecture.

Version 2.0 or later of the common language runtime is currently loaded and rawAssembly was compiled with a later version.

Remarks

The trust level of an assembly that is loaded by using this method is the same as the trust level of the calling assembly. To load an assembly from a byte array with the trust level of the application domain, use the Load(Byte[], Byte[], SecurityContextSource) method overload. For more information about the use of evidence with overloads of the Load method that take byte arrays, see the Load(Byte[], Byte[], Evidence) method overload.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

Note that this method overload always creates a new Assembly object with its own mapping.

Loads the assembly with a common object file format (COFF)-based image containing an emitted assembly, optionally including symbols for the assembly. The assembly is loaded into the application domain of the caller.

Version 2.0 or later of the common language runtime is currently loaded and rawAssembly was compiled with a later version.

Remarks

The trust level of an assembly that is loaded by using this method is the same as the trust level of the calling assembly. To load an assembly from a byte array with the trust level of the application domain, use the Load(Byte[], Byte[], SecurityContextSource) method overload. For more information about the use of evidence with overloads of the Load method that take byte arrays, see the Load(Byte[], Byte[], Evidence) method overload.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

Note that this method overload always creates a new Assembly object with its own mapping.

Version 2.0 or later of the common language runtime is currently loaded and assemblyString was compiled with a later version.

Examples

The following example loads an assembly given its fully qualified name, and lists all the types contained in the specified assembly. For this code example to run, you must provide the fully qualified assembly name. For information about how to obtain the fully qualified assembly name, see Assembly Names.

Remarks

The long form of an assembly name consists of its simple name (such as "System" for the System.dll assembly) along with its version, culture, public key token, and optionally its processor architecture. It corresponds to the assembly's FullName property. The following example illustrates the use of a long name to load the System.dll assembly for the .NET Framework 4.

FileLoadException is thrown if assemblyString specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name.

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 Load method with no Evidence parameter, the assembly is loaded with the evidence that the loader supplies.

When you use a Load method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the Load method supersede pieces of evidence supplied by the loader.

When you use a Load method overload with a Byte[] parameter to load a common object file format (COFF) image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases.

Note

In the .NET Framework version 1.0 and in version 1.1 without SP1, when you use a Load method overload with a Byte[] parameter to load a 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 Load 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.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

In the .NET Framework version 2.0, processor architecture is added to assembly identity, and can be specified as part of assembly name strings. For example, "ProcessorArchitecture=msil". However, the recommended way to specify an assembly name is to create an AssemblyName object and pass it to an appropriate overload of the Load method. See AssemblyName.ProcessorArchitecture.

[System.Obsolete]
[System.Obsolete("This method is obsolete and will be removed in a future release of the .NET Framework. Please use an overload of Load which does not take an Evidence parameter. See http://go.microsoft.com/fwlink/?LinkID=155570 for more information.")]
public static System.Reflection.Assembly Load (System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity);

assemblyRef specifies a remote assembly, but the ability to execute code in remote assemblies is disabled. See <loadFromRemoteSources>.

Remarks

FileLoadException is thrown if assemblyRef specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name. Starting with .NET Framework 4, because execution of code in remote assemblies is disabled by default, a FileLoadException is also thrown if assemblyRef specifies a remote assembly. To enable execution of code loaded from remote locations, you can use the <loadFromRemoteSources> configuration element.

Note

Do not use an AssemblyName with only the CodeBase property set. The CodeBase property does not supply any elements of the assembly identity (such as name or version), so loading does not occur according to load-by-identity rules, as you would expect from the Load method. Instead, the assembly is loaded using load-from rules. For information about the disadvantages of using the load-from context, see the Assembly.LoadFrom method overload or Best Practices for Assembly Loading.

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 Load method with no Evidence parameter, the assembly is loaded with the evidence that the loader supplies.

When you use a Load method with an Evidence parameter, pieces of evidence are merged. Pieces of evidence supplied as an argument to the Load method supersede pieces of evidence supplied by the loader.

When you use a Load method overload with a Byte[] parameter to load a common object file format (COFF) image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases.

Note

In the .NET Framework version 1.0 and in version 1.1 without SP1, when you use a Load method overload with a Byte[] parameter to load a 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 Load 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.

Reflecting on C++ executable files might throw a BadImageFormatException. This is most likely caused by the C++ compiler stripping the relocation addresses or the .reloc section from your executable file. To preserve the .reloc address for your C++ executable file, specify /fixed:no when you are linking.

Note

If both the AssemblyName.Name property and the AssemblyName.CodeBase property are set, the first attempt to load the assembly uses the display name (including version, culture, and so on, as returned by the Assembly.FullName property). If the file is not found, CodeBase is used to search for the assembly. If the assembly is found using CodeBase, the display name is matched against the assembly. If the match fails, a FileLoadException is thrown.

If you call the Load 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.