.Net Assembly Interview Questions and Answers

Assemblies are the basic building blocks required for any application to function in the .NET realm. They are partially compiled code libraries that form the fundamental unit of deployment, versioning, activation scoping, reuse, and security. Typically, assemblies provide a collection of types and resources that work together to form a logical unit of functionality. They are the smallest deployable units of code in .NET. Compared to the executable files assemblies are far more reliable, more secure, and easy to manage. An assembly contains a lot more than the Microsoft Intermediate Language (MSIL) code that is compiled and run by the Common Language Runtime (CLR). In other words, you can say that an assembly is a set of one or more modules and classes compiled in MSIL, and metadata that describes the assembly itself, as well as the functionalities of the assembly classes.

An assembly is a logical unit that is made up of the following four different types of components:

• Assembly manifest
• MSIL source code
• Type metadata
• Resources

The following are the two types of assemblies:

• Private Assembly – Refers to the assembly that is used by a single application. Private assemblies are kept in a local folder in which the client application has been installed.
• Public or Shared Assembly – Refers to the assembly that is allowed to be shared by multiple applications. A shared assembly must reside in Global Assembly Cache (GAC) with a strong name assigned to it.

For example, imagine that you have created a DLL containing information about your business logic. This DLL can be used by your client application. In order to run the client application, the DLL must be included in the same folder in which the client application has been installed. This makes the assembly private to your application. Now suppose that the DLL needs to be reused in different applications. Therefore, instead of copying the DLL in every client application folder, it can be placed in the global assembly cache using the GAC tool. These assemblies are called shared assemblies.

No, a DLL file can contain the compiled code of only one programming language.

There is no limit to the maximum number of classes that can be contained in a DLL file.

Satellite assemblies are assemblies that are used to deploy language and culture specific resources for an application. In an application, a separate product ID is assigned to each language and a satellite assembly is installed in a language specific sub-directory.

No, versioning is not applicable to private assemblies as these assemblies reside in their individual folders. Versioning can be applied to GAC only.

An assembly metadata describes every data type and member defined in the code. It stores the description of an assembly, such as name, version, culture, public key of an assembly along with the types exported, other assemblies’ dependent on this assembly, and security permissions needed to run the application. In addition, it stores the description of types, such as the name, visibility, base class, interfaces implemented, and members, such as methods, fields, properties, events, and nested types.

It also stores attributes. Metadata is stored in binary format. Therefore, metadata of an assembly is sharable among applications that execute on various platforms. It can also be exported to other applications to give information about the services and various features of an application.

Assemblies maintain all their information in a special unit called the manifest. Every assembly has a manifest.

The followings are the contents of an Assembly Manifest:

• Assembly name – Represents a text string that specifies the assembly’s name.
• Version number – Represents a major and minor version number, as well as a revision and build number. The CL.R makes use of these numbers to enforce version policy.
• Culture – Represents information of the culture or language, which the assembly supports. An assembly is a container of only resources containing culture- or language-specific information.
• Strong name information – Represents the public key from the publisher, if a strong name is assigned to an assembly.
• List of all files in the assembly – Represents a hash of each file contained in the assembly and a file name.
• Type reference information – Represents the information used at the runtime to map a type reference to the file that contains its declaration and implementation.
• Information on referenced assemblies – Represents a list of other assemblies that are statically referenced by the assembly. Each reference includes the names of dependent assemblies, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.

False.

The Native Image Generator (Ngen.exe) is a tool that creates a native image from an assembly and stores that image to native image cache on the computer. Whenever, an assembly is run, this native image is automatically used to compile the original assembly. In this way, this tool improves the performance of the managed application by loading and executing an assembly faster.

Note that native images are files that consist of compiled processor-specific machine code. The Ngen.exe tool installs these files on to the local computer.

The Ildasm.exe utility.

The Strong Name utility (sn.exe) helps in creating unique public-private key pair files that are called strong name files and signing assemblies with them. It also allows key management, signature generation, and signature verification.

You can use different versions of private assemblies in the same application without a re-build by specifying the assembly version in the AssemblyInfo.cs or AssemblyInfo.vb file.

GAC is a central repository (cache) in a system in which assemblies are registered to share among various applications that execute on local or remote machines. .NET Framework provides the GAC tool (gacutil.exe utility), which is used to view and change the content of GAC of a system. Adding new assemblies to GAC and removing assemblies from GAC are some of the tasks that can be performed by using the gacutil.exe utility. GAC can contain multiple versions of the same .NET assembly. CLR checks GAC for a requested assembly before using information of configuration files.

The gacutil.exe /i <assembly name> – is the command that is used to install an assembly in GAC. Users use the Command Prompt of Visual Studio to install an assembly in GAC by using this command.

You can see all the assemblies installed in the GAC using the GAC viewer, which is located at the <WinDrive>:<WinDir>\assembly directory, where <WinDir> is windows in Windows XP or windows in Windows Vista or WinNT in Windows 2000. Apart from the list of assemblies, the assembly viewer also shows relevant information, such as the global assembly name, version, culture, and the public key token.

Information for the version of assembly is stored inside the assembly manifest.

Whenever, an assembly is deployed in GAC to make it shared, a strong name needs to be assigned to it for its unique identification. A strong name contains an assembly’s complete identity – the assembly name, version number, and culture information of an assembly. A public key and a digital signature, generated over the assembly, are also contained in a strong name. A strong name makes an assembly identical in GAC.

EXE

• It is an executable file, which can be run independently.
• EXE is an out-process component, which means that it runs in a separate process.
• It cannot be reused in an application.
• It has a main function.

DLL

• It is Dynamic Link Library that is used as a part of EXE or other DLLs. It cannot be run independently.
• It runs in the application process memory, so it is called as in-process component.
• It can be reused in an application.
• It does not have a main function.

An assembly can be referenced by using the gacutil.exe utility with the /r option. The /r option requires a          reference type, a reference ID, and a description.

True.

The namespace keyword is used to declare a scope. This namespace scope lets you organize code and gives you a way to create globally unique types.

Within a namespace, you can declare one or more of the following types:

• another namespace
• class
• interface
• struct
• enum
• delegate

Whether or not you explicitly declare a namespace in a C# source file, the compiler adds a default namespace. This unnamed namespace, sometimes referred to as the global namespace, is present in every file. Any identifier in the global namespace is available for use in a named namespace.

Namespaces implicitly have public access and this is not modifiable.

It is possible to define a namespace in two or more declarations.e.g: namespace MyCompany.Proj1{ class MyClass { }} namespace MyCompany.Proj1{ class MyClass1 { }}

Namespaces have the following properties:

• They organize large code projects.
• They are delimited by using the. operator.
• The using directive obviates the requirement to specify the name of the namespace for every class.
• The global namespace is the “root” namespace: global:System will always refer to the .NET Framework namespace System.

The using directive has two uses:

• To allow the use of types in a namespace so that you do not have to qualify the use of a type in that namespace
• To create an alias for a namespace or a type. This is called a using alias directive.

The scope of a using directive is limited to the file in which it appears. Create a using alias to make it easier to qualify an identifier to a namespace or type.

Namespaces come in two categories: user-defined and system-defined. User-defined namespaces are namespaces defined in your code.

A boundary that the common language runtime establishes around objects created within the same application scope. Application domains help isolate objects created in one application from those created in other applications so that run-time behaviour is predictable. Multiple application domains can exist in a single process.

A collection of one or more files versioned and deployed as a unit. It contains code that the common language runtime executes. It forms a security boundary. An assembly is the unit at which permissions are requested and granted. It forms a type boundary. Every type’s identity includes the name of the assembly in which it resides. It forms a reference scope boundary. It forms a version boundary. It forms a deployment unit.

assemblies can be an efficient way to manage resources in larger projects. Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly.

Assemblies have the following properties:

• Assemblies are implemented as .exe or .dll files.
• You can share an assembly between applications by putting it in the Global Assembly Cache.
• Assemblies must be strong-named before they can be included in the Global Assembly Cache.
• Assemblies are only loaded into memory if they are required.
• You can programmatically obtain information about an assembly by using reflection
• If you want to load an assembly only to inspect it, use a method such as ReflectionOnlyLoadFrom.
• You can use two versions of the same assembly in a single application.

Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

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

private assembly: An assembly that is available only to clients in the same directory structure as the assembly.

shared assembly: An assembly that can be referenced by more than one application. An assembly must be explicitly built to be shared by giving it a cryptographically strong name.

satellite assembly: A .NET Framework assembly containing resources specific to a given language. Using satellite assemblies, you can place the resources for difference languages in different assemblies, and the correct assembly is loaded into memory only if the user elects to view that application in that language.

Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.

There are several ways to deploy an assembly into the global assembly cache:

• Use an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.
• Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the Windows Software Development Kit (SDK).
• Use Windows Explorer to drag assemblies into the cache.
• Assemblies deployed in the global assembly cache must have a strong name. When an assembly is added to the global assembly cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change

A strong name consists of the assembly’s identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file using the corresponding private key.

You can ensure that a name is globally unique by signing an assembly with a strong name. In particular, strong names satisfy the following requirements:

• Strong names guarantee name uniqueness by relying on unique key pairs.
• Strong names protect the version lineage of an assembly. A strong name can ensure that no one can produce a subsequent version of your assembly.
• Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built.
• When you reference a strong-named assembly, you expect to get certain benefits, such as versioning and naming protection. If the strong-named assembly then references an assembly with a simple name, which does not have these benefits, you lose the benefits you would derive from using a strong-named assembly and revert to DLL conflicts. Therefore, strong-named assemblies can only reference other strong-named assemblies.

An assembly manifest contains all the metadata needed to specify the assembly’s version requirements and security identity, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. The assembly manifest can be stored in either a PE file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE file that contains only assembly manifest information.

• Enumerates the files that make up the assembly.
• Governs how references to the assembly’s types and resources map to the files that contain their declarations and implementations.
• Enumerates other assemblies on which the assembly depends.
• Provides a level of indirection between consumers of the assembly and the assembly’s implementation details.
• Renders the assembly self-describing.

• Assembly name
• Version number
• Culture
• Strong name information
• List of all files in the assembly
• Type reference information
• Information on referenced assemblies

In general, a static assembly can consist of four elements:

• The assembly manifest, which contains assembly metadata.
• Type metadata.
• Microsoft intermediate language (MSIL) code that implements the types.
• A set of resources.

• There are several ways to group these elements in an assembly. You can group all elements in a single physical file, which is shown in the following illustration.
• Single-file assembly·
• Alternatively, the elements of an assembly can be contained in several files. These files can be modules of compiled code (.netmodule), resources (such as .bmp or .jpg files), or other files required by the application.

• Create a multifile assembly when you want to combine modules written in different languages and to optimize downloading an application by putting seldom used types in a module that is downloaded only when needed.
• The files that make up a multifile assembly are not physically linked by the file system. Rather, they are linked through the assembly manifest and the common language runtime manages them as a unit.

Metadata is binary information describing your program that is stored either in a common language runtime portable executable (PE) file or in memory. When you compile your code into a PE file, metadata is inserted into one portion of the file, while your code is converted to Microsoft intermediate language (MSIL) and inserted into another portion of the file. Every type and member defined and referenced in a module or assembly is described within metadata. When code is executed, the runtime loads metadata into memory and references it to discover information about your code’s classes, members, inheritance, and so on.

Metadata describes every type and member defined in your code in a language-neutral manner.

Metadata stores the following information:

• Description of the assembly.
• Identity (name, version, culture, public key).
• The types that are exported.
• Other assemblies that this assembly depends on.
• Security permissions needed to run.
• Description of types.
• Name, visibility, base class, and interfaces implemented.
• Members (methods, fields, properties, events, nested types).
• Additional descriptive elements that modify types and members.