Explore topic-wise InterviewSolutions in Current Affairs.

True.

True.

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.

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.

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.

EXE:

DLL:

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.

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.

INFORMATION for the VERSION of assembly is stored inside the assembly MANIFEST.

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

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.

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.

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.

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.

The Ildasm.exe UTILITY.

The Ildasm.exe utility.

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 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.

False.

False.

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.

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.

No, VERSIONING is not APPLICABLE to private assemblies as these assemblies reside in their individual FOLDERS. Versioning can be APPLIED to GAC only.

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

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.

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:

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.

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.

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.

The using directive has two uses:

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.