.

.

.

In this command, the module name arguments specify the name of each module to include in the assembly. The /main: option specifies the method name that is the assembly's entry point. The /out: option specifies the name of the output file, which contains assembly metadata. The /target: option specifies that the assembly is a console application executable (.exe) file, a Windows executable (.win) file, or a library (.lib) file.

In the following example, Al.exe creates an assembly that is a console application executable called myAssembly.exe. The application consists of two modules called personnel.netmodule and admin.netmodule, and the executable file called myAssembly.exe, which contains only assembly metadata. The entry point of the assembly is the Main method in the class personnel, which is located in personnel.dll.

al personnel.netmodule Admin.netmodule /main:..Main /out:myAssembly.exe /target:exe

Static and dynamic assemblies

Reflection emit provides many ways to create dynamic assemblies. Dynamic assemblies can be created using the various System.AppDomain.DefineDynamicAssembly methods. DefineDynamicAssembly returns an AssemblyBuilder object. DefineDynamicAssembly requires the caller to specify the AssemblyBuilderAccess enumeration value. The enumeration value specifies whether the dynamic assembly will be run only, saved only, or run and/or saved. Some of the methods require the caller to supply evidence, which is the set of information that constitutes input to security policy decisions, such as which permissions can be granted to code. Other methods require the caller to request permissions. Three kinds of permission requests exist: required, optional, and refused.

The following list identifies the various ways in which dynamic assemblies can be defined:

1. Define a named dynamic assembly.

2. Define a named dynamic assembly given the directory for saving the assembly.

3. Define a named dynamic assembly given the evidence.

4. Define a named dynamic assembly given the permission requests.

5. Define a named dynamic assembly given the evidence and the directory for saving the assembly.

6. Define a named dynamic assembly given the permission requests and the directory for saving the assembly.

7. Define a named dynamic assembly given the evidence and the permission requests.

8. Define a named dynamic assembly given the evidence, the permission requests, and the directory for saving the assembly.

9. Define a named dynamic assembly given the evidence, the permission requests, the directory for saving the assembly, and a Boolean parameter indicating whether the creation of modules, types, and members in the dynamic assembly should be synchronized.

A persistent dynamic assembly is saved using the AssemblyBuilder.Save method. The Save method specifies the name of the file to which the assembly should be written.

Private and shared assemblies

Assemblies can be private or shared: by default, most simple C# programs consist of a private assembly because they are not intended to be used by other applications.

In order to share an assembly with other applications, it must be placed in the Global Assembly Cache (GAC).

Sharing an assembly

• Create your assembly.
• Assign a strong name to your assembly.
• Assign version information to your assembly.
• Add your assembly to the Global Assembly Cache.
• Access the types contained in the assembly from the other applications.

Satellite and Resource-only assemblies

Satellite assemblies are often used to deploy language-specific resources for an application. These language-specific assemblies work in side-by-side execution because the application has a separate product ID for each language and installs satellite assemblies in a language-specific subdirectory for each language. When uninstalling, the application removes only the satellite assemblies associated with a given language and .NET Framework version. No core .NET Framework files are removed unless the last language for that .NET Framework version is being removed.

For example, English and French editions of the .NET Framework version 2.0 share the same core files. The French .NET Framework version 2.0 adds satellite assemblies with localized resources in a \fr subdirectory. An application that supports the .NET Framework version 2.0, regardless of its language, always uses the same core runtime files.

The CurrentUICulture property can be set on a per-application or per-thread basis. The application returns resources that have been localized according to the CurrentUICulture property, assuming localized files for that language have been installed. For example, an application can return English resources while running on the French Windows operating system with a French version of the .NET Framework version 2.0 installed.

The hub and spoke model described in the Packaging and Deploying Resources topic is the recommended design implementation for developing applications with resources.

The hub and spoke model requires that you place resources in specific locations, so that they can be easily located and use. The common language runtime will not be able to locate them if the resources are not properly named or located. As a result, the runtime uses the default resource set.

Compiling Satellite Assemblies

Use the Assembly Linker (Al.exe) to compile .resources files into satellite assemblies. Al.exe creates an assembly from the .resources files that you specify. By definition, satellite assemblies can only contain resources. They cannot contain any executable code.

The following Al.exe command creates a satellite assembly for the application MyApp from the file strings.de.resources.

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll

The following Al.exe command also creates a satellite assembly for the application MyApp from the file strings.de.resources. The /template option causes the satellite assembly to inherit assembly metadata from the parent assembly MyApp.dll.

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll

/template:MyApp.dll

The following table explains the Al.exe options used in these examples in more detail.

<< Prev - Next >>