1 Assembly 1.

What is an Attributes Attribute : Attributes are descriptive tags that provide additional information about programming elements such as types, fields, methods, and properties. Other applications, such as the Visual Basic compiler, can refer to the extra information in attributes to determine how these items can be used. Functionality and Capabilities of Attributes You can apply one or more attributes to entire assemblies, modules, or smaller program elements such as classes and properties. Attributes can accept arguments in the same way as methods and properties. Attributes fall into two groups: those that are used by the .NET Framework and Visual Basic .NET, and custom attributes that are meaningful only to specific applications. While the .NET Framework contains many useful attributes, you can define your own custom attributes if necessary. Custom attributes are defined in attribute classes based on the System.Attribute class. Attribute classes themselves use AttributeUsage to provide additional information about how the attribute can be used. The process of retrieving metadata from attributes is called reflection. Reflection involves using tools that allow objects to retrieve and examine metadata about their own members. Metadata Attribute The first type I will refer to as a metadata attribute - it allows some data to be attached to a class or method. This data becomes part of the metadata for the class, and (like other class metadata) can be accessed via reflection. An example of a metadata attribute is [serializable], which can be attached to a class and means that instances of the class can be serialized. [serializable] public class CTest {} Custom Attribute Custom attributes are user-defined attributes that provide additional information about program elements. You define custom attributes in attribute classes based on the System.Attribute class. Attribute classes themselves use an attribute called AttributeUsage to provide information about how the attribute can be used. Specifying Inherited = True indicates that an attribute can propagate to derived classes. Setting the AllowMultiple property to True allows you to apply more than one instance of the attribute to a program element. The AttributeTargets enumeration lets you define which kinds of program elements your attribute can apply to. In the following code, the AttributeUsage attribute specifies an attribute that can be applied to any type of item, inherited, and applied only once:
False)> <AttributeUsage(AttributeTargets.All, Inherited := True, AllowMultiple :=

2 2. You can use the Or operator to combine multiple items from the AttributeTargets enumeration, as in the following code:
<AttributeUsage(AttributeTargets.Class Or AttributeTargets.Method)>

3. How can I produce an assembly? The simplest way to produce an assembly is directly from a .NET compiler. For example, the following C# program: public class CTest { public CTest() { System.Console.WriteLine( "Hello from CTest" ); } } can be compiled into a library assembly (dll) like this: csc /t:library ctest.cs You can then view the contents of the assembly by running the "IL Disassembler" tool that comes with the .NET SDK. Alternatively you can compile your source into modules, and then combine the modules into an assembly using the assembly linker (al.exe). For the C# compiler, the /target:module switch is used to generate a module instead of an assembly. 2. What is the difference between a private assembly and a shared assembly? Location and visibility: A private assembly is normally used by a single application, and is stored in the application's directory, or a sub-directory beneath. A shared assembly is normally stored in the global assembly cache, which is a repository of assemblies maintained by the .NET runtime. Shared assemblies are usually libraries of code which many applications will find useful, e.g. the .NET framework classes. Versioning: The runtime enforces versioning constraints only on shared assemblies, not on private assemblies. 3. How do assemblies find each other? By searching directory paths. There are several factors which can affect the path (such as the AppDomain host, and application configuration files), but for private assemblies the search path is normally the application's directory and its sub-directories. For shared assemblies, the search path is normally same as the private assembly path plus the shared assembly cache. 4. How does assembly versioning work? Each assembly has a version number called the compatibility version. Also each reference to an assembly (from another assembly) includes both the name and version of the referenced assembly. This version number is physically represented as a four-part number with the following format:

3 <major version>.<minor version>.<build number>.<revision> For example, version 1.5.1254.0 indicates 1 as the major version, 5 as the minor version, 1254 as the build number, and 0 as the revision number. Changes to the major and Minor assembly number of the assembly signal that the assembly is no longer compatible with previous version. Incrementing the revision and build number indicates that the new version is compatible with the previous version. However, this is just the default guideline - it is the version policy that decides to what extent these rules are enforced. The version policy can be specified via the application configuration file. Versioning is only applied to shared assemblies, not private assemblies. 5. What are the diff between private assemblies and shared assemblies? A private assembly is used only by a single application, A shared assembly is one that can be referenced by more than one application. A private assembly is stored in the application directory or sub directory And a shared assembly is stored in GAC. In order to share an assembly, the assembly must be explicitly built for this purpose by giving it a strong name (referred to as a strong name). By contrast, a private assembly name need only be unique within the application that uses it. 9. If I want to build a shared assembly, does that require the overhead of signing and managing key pairs? Building a shared assembly does involve working with cryptographic keys. Only the public key is strictly needed when the assembly is being built. Compilers targeting the .NET Framework provide command line options (or use custom attributes) for supplying the public key when building the assembly. It is common to keep a copy of a common public key in a source database and point build scripts to this key. Before the assembly is shipped, the assembly must be fully signed with the corresponding private key. This is done using an SDK tool called SN.exe (Strong Name). Strong name signing does not involve certificates like Authenticode does. There are no third party organizations involved, no fees to pay, and no certificate chains. In addition, the overhead for verifying a strong name is much less than it is for Authenticode. However, strong names do not make any statements about trusting a particular publisher. Strong names allow you to ensure that the contents of a given assembly haven't been tampered with, and that the assembly loaded on your behalf at run time comes from the same publisher as the one you developed against. But it makes no statement about whether you can trust the identity of that publisher.

4 10. What is satellite assembly ? 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. Option Description /t:lib The /t option specifies that your satellite assembly is compiled to a library (.dll ) file. A satellite assembly cannot be executed because it does not contain code and is not an application's main assembly. Therefore, you must save satellite assemblies as DLLs. /embed:strings.de.resources The /embed option specifies the name of the source file to use when Al.exe compiles the assembly. Note that you can embed multiple .resources files in a satellite assembly. However, if you are following the hub and spoke model, you must compile one satellite assembly for each culture. You can, however, create separate .resources files for strings and objects. /culture:de The /culture option specifies the culture of the resource to compile. The runtime uses this information when it searches for the resources for a specified culture. If you omit this option, Al.exe still compiles the resource, but the runtime will not be able to find it when a user requests it. /out:MyApp.resources.dll The /out option specifies the name of the output file. The name must follow the naming standard baseName.resources.extension, where the

5 baseName is the name of the main assembly, and the extension is a viable extension (such as .dll). Note that the runtime is not able to determine the culture of a satellite assembly based on its output file name. Therefore it is important to specify a culture with the /culture option described above. /template:filename The /template option specifies an assembly from which to inherit all assembly metadata, except the culture field. The assembly that the satellite assembly inherits from must have a strong name. Compiling Satellite Assemblies With Strong Names If you want to install satellite assemblies into the global assembly cache, they must have strong names. Strong-named assemblies are signed with a valid public/private key pair. When you are developing an application, it is unlikely that you will have access to the final public/private key pair. In order to install a satellite assembly in the global assembly cache and ensure that it works as expected, you can use a technique called delayed signing. When you delay sign an assembly, you reserve space in the file for the strong name signature at build time. The actual signing is delayed until a later date when the final public/private key pair is available. Obtaining the Public Key In order to delay sign an assembly you must have access to the public key. You can create a public key using the Strong Name Tool (Sn.exe). The following Sn.exe command creates a test public/private key pair and saves it in the file TestKeyPair.snk. The k option specifies to Sn.exe to create a new key pair and save it in the specified file. sn k TestKeyPair.snk You can extract the public key from the file containing the test key pair. The following command extracts the public key from TestKeyPair.snk and saves it in PublicKey.snk. sn p TestKeyPair.snk PublicKey.snk Delay Signing an Assembly Once you have obtained or created the public key, use the Assembly Linker (Al.exe) to compile the assembly and specify delayed signing. The following Al.exe command creates a strong-named satellite assembly for the application MyApp from the strings.ja.resources file. al /t:lib /embed:strings.ja.resources /culture:ja /out:MyApp.resources.dll /delay+ /keyfile:PublicKey.snk

6 The /delay+ option specifies to delay sign the assembly. The /keyfile: option specifies the name of the key file containing the public key to use to delay sign the assembly. Note that strong-named assemblies have version information that the runtime uses to determine which assembly to use to meet a binding request. Re-signing an Assembly At some later date, a delay signed satellite assembly must be re-signed with the real key pair. You can do this using Sn.exe. The following Sn.exe command signs MyApp.resources.dll with the real key pair stored in the file RealKeyPair.snk. The R option specifies to Sn.exe to re-sign a previously signed or delay signed assembly. sn R MyApp.resources.dll RealKeyPair.snk Installing a Satellite Assembly in the Global Assembly Cache In the resource fallback process, the global assembly cache is the first location the runtime searches for resources. A satellite assembly that you have compiled with a strong name is ready to install in the global assembly cache. You can install assemblies into the cache using the Global Assembly Cache Tool (Gacutil.exe). The following Gacutil.exe command installs MyApp.resources.dll into the global assembly cache. gacutil /i:MyApp.resources.dll The /i option specifies to Gacutil.exe to install the specified assembly into the global assembly cache. As a result of this command, an entry is placed in the cache, which allows entries in this .resources file to be accessed. After being installed in the cache, the specified resource is available to all applications that are designed to use it. Directory Locations for Satellite Assemblies Not Installed in the Global Assembly Cache After you have compiled your satellite assemblies, they all have the same name. The runtime differentiates between them based upon the culture specified at compile time with Al.exe's /culture option and by each assembly's directory location. You must place your satellite assemblies in expected directory locations. The following illustration shows a sample directory structure and location requirements for console applications that you are not installing in the global assembly cache. The items with .txt and .resources file extensions will not ship with the final application. These are the intermediate resource files used to create the final satellite resource assemblies. In this example, you could substitute .resx files for the .txt files. The .resx files are the only type of intermediate resource file that can contain objects.

7 11. What is the difference between a namespace and an assembly name? A logical naming scheme for grouping related types. The .NET Framework uses a hierarchical naming scheme for grouping types into logical categories of related functionality, such as the ASP.NET technology or remoting functionality. For example, types MyCompany.FileAccess.A and MyCompany.FileAccess.B might be logically expected to have functionality related to file access. Design tools can use namespaces to make it easier for developers to browse and reference types in their code. The concept of a namespace is orthogonal to that of an assembly: a single assembly can contain types whose hierarchical names have different namespace roots, and a logical namespace root can span multiple assemblies. 12. How can I see what assemblies are installed in the global assembly cache? The .NET Framework ships with a Windows shell extension for viewing the assembly cache. Navigating to % windir%\assembly with the Windows Explorer activates the viewer. 13. How many manifest an assembly can have? One 14. How to identify a shared assembly? An assembly that is placed in GAC and has a strong name is a shared assembly Global Assembly Cache Tool (Gacutil.exe) : The Global Assembly Cache tool allows you to view and manipulate the contents of the global assembly cache and download cache. 15. Is it possible to register an assembly with the existing name in GAC? (two different assemblies with the same name) No