AppDomain.DefineDynamicAssembly Method (AssemblyName, AssemblyBuilderAccess, String, Evidence, PermissionSet, PermissionSet, PermissionSet, Boolean, IEnumerable<CustomAttributeBuilder>)
Defines a dynamic assembly with the specified name, access mode, storage directory, evidence, permission requests, synchronization option, and custom attributes.
Assembly: mscorlib (in mscorlib.dll)
[ObsoleteAttribute("Assembly level declarative security is obsolete and is no longer enforced by the CLR by default. See http://go.microsoft.com/fwlink/?LinkID=155570 for more information.")] public AssemblyBuilder DefineDynamicAssembly( AssemblyName name, AssemblyBuilderAccess access, string dir, Evidence evidence, PermissionSet requiredPermissions, PermissionSet optionalPermissions, PermissionSet refusedPermissions, bool isSynchronized, IEnumerable<CustomAttributeBuilder> assemblyAttributes )
The unique identity of the dynamic assembly.
The mode in which the dynamic assembly will be accessed.
The name of the directory where the dynamic assembly will be saved. If dir is null, the current directory is used.
The evidence that is supplied for the dynamic assembly. The evidence is used unaltered as the final set of evidence used for policy resolution.
The required permissions request.
The optional permissions request.
The refused permissions request.
true to synchronize the creation of modules, types, and members in the dynamic assembly; otherwise, false.
Return ValueType: System.Reflection.Emit.AssemblyBuilder
A dynamic assembly with the specified name and features.
Use this method overload to specify attributes that do not work correctly unless they are applied when a dynamic assembly is created. For example, security attributes such as SecurityTransparentAttribute and SecurityCriticalAttribute do not work correctly if they are added after a dynamic assembly has been created.
The permission requests specified for the requiredPermissions, optionalPermissions, and refusedPermissions parameters are used only if the evidence parameter is also supplied, or if the dynamic assembly is saved and reloaded into memory.
When you develop code that emits dynamic assemblies, we recommend that you include the SecurityPermissionFlag.SkipVerification flag in the refusedPermissions parameter. The inclusion of this flag ensures that the Microsoft intermediate language (MSIL) will be verified. This technique will detect the unintentional generation of unverifiable code, which otherwise is very difficult to detect. A limitation of this technique is that it also causes SecurityException to be thrown when it is used with code that demands full trust.
Only fully trusted callers can supply evidence when defining a dynamic Assembly. The runtime maps the Evidence through the security policy to determine the granted permissions. Partially trusted callers must supply null for the evidence parameter. If evidence is null, the runtime copies the permission sets (that is, the current grant and deny sets) from the caller's assembly to the dynamic assembly that is being defined, and marks the policy as resolved.
If the dynamic assembly is saved to disk, subsequent loads will get grants based on policies that are associated with the location where the dynamic assembly was saved.
If isSynchronized is true, the following methods of the resulting AssemblyBuilder will be synchronized: DefineDynamicModule, DefineResource, AddResourceFile, GetDynamicModule, SetEntryPoint, and Save. If two of these methods are called on different threads, one will block until the other is completed.
This method overload is introduced in the .NET Framework 3.5.
Available since 2.0