.NET Tutorials, Forums, Interview Questions And Answers
Welcome :Guest
Sign In
Win Surprise Gifts!!!

Top 5 Contributors of the Month
Kaviya Balasubramanian
Sgraph Infotech
Imran Ghani

Home >> Interview Question >> ADO.Net >> Post New Question Subscribe to Interview Questions

What is the location of Global Assembly Cache on the system?

Posted By :shahin     Posted Date :May 29, 2009    Points :10   Category :ADO.Net 

You can also find related Interview Question to What is the location of Global Assembly Cache on the system?  below: 

where is global assembly cache location in system?

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. (More...)

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. (More...)

Can you place two .dll files with the same name in GAC (Global Assembly Cache)?

Yes, provided both have different versions.
GAC is a Folder that contains .dll that have strong name. So we can keep myproject.dll and myproject.dll two files into GAC with different version like and (More...)

Is the ASP.NET AJAX Control Toolkit(AjaxControlToolkit.dll) installed in the Global Assembly Cache?

No. You must copy the AjaxControlToolkit.dll assembly to the /Bin folder in your application. (More...)

What is difference between System.Web.Caching.Cache and System.Web.HttpContext.Current.Cache ?

System.Web.Caching.Cache : Class/type used for caching
System.Web.HttoContect.Current.Cache : The instance of cache class for current HTTP context from a web request (Gets cache object from current application domain) (More...)

What is Assembly?

Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.
Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:
It contains code that the common language runtime executes. Microsoft intermediate language (MSIL) code in a portable executable (PE) file will not be executed if it does not have an associated assembly manifest. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main).
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. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly.
It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.
It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies.
It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded.
It is the unit at which side-by-side execution is supported.
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 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.
There are several ways to create assemblies. You can use development tools, such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies. (More...)

What are the contents of assembly?

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. (More...)

What is Assembly manifest? what all details the assembly manifest will contain?

Every assembly, whether static or dynamic, contains a collection of data that describes how the elements in the assembly relate to each other. The assembly manifest contains this assembly metadata. 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.

It contains Assembly name, Version number, Culture, Strong name information, List of all files in the assembly, Type reference information, Information on referenced assemblies. (More...)

Difference between assembly manifest & metadata?

assembly manifest - An integral part of every assembly that renders the assembly self-describing. The assembly manifest contains the assembly's metadata. The manifest establishes the assembly identity, specifies the files that make up the assembly implementation, specifies the types and resources that make up the assembly, itemizes the compile-time dependencies on other assemblies, and specifies the set of permissions required for the assembly to run properly. This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.

metadata - Information that describes every element managed by the common language runtime: an assembly, loadable file, type, method, and so on. This can include information required for debugging and garbage collection, as well as security attributes, marshaling data, extended class and member definitions, version binding, and other information required by the runtime. (More...)

What is type system unification?

The goal of type system unification is to bridge the gap between value types and reference types that exists in most languages. For example, a Stack class can provide Push and Pop methods that take and return object values.

public class Stack
public object Pop() {...}
public void Push(object o) {...}
Because C# has a unified type system, the Stack class can be used with elements of any type, including value types like int. (More...)

What is the common type system (CTS)?

The common type system is a rich type system, built into the Common Language Runtime, that supports the types and operations found in most programming languages. The common type system supports the complete implementation of a wide range of programming languages. (More...)

What is an assembly?

An assembly is the primary building block of a .NET Framework application. It is a collection of functionality that is built, versioned, and deployed as a single implementation unit (as one or more files). All managed types and resources are marked either as accessible only within their implementation unit, or as accessible by code outside that unit.
Assemblies are self-describing by means of their manifest, which is an integral part of every assembly. The manifest:
Establishes the assembly identity (in the form of a text name), version, culture, and digital signature (if the assembly is to be shared across applications).
Defines what files (by name and file hash) make up the assembly implementation.
Specifies the types and resources that make up the assembly, including which are exported from the assembly.
Itemizes the compile-time dependencies on other assemblies.
Specifies the set of permissions required for the assembly to run properly.
This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The runtime can determine and locate the assembly for any running object, since every type is loaded in the context of an assembly. Assemblies are also the unit at which code access security permissions are applied. The identity evidence for each assembly is considered separately when determining what permissions to grant the code it contains.
The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible. (More...)

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. (More...)

Quick Links For Interview Questions Categories:
ASP.Net Windows Application   .NET Framework   C#   VB.Net   ADO.Net  
Sql Server   SharePoint   Silverlight   OOPs   JQuery   JavaScript/VBScript
Biztalk Patten/Practices .IIS WCF WPF WWF
Networking Aptitude Others   All      

Find questions, FAQ's and their answers related to .NET, C#, Vb.Net, Sql Server and many more.

Now you can find lots of .NET, C#, Vb.Net, SQL Server,Windows, ASP.Net related Questions and their Answers here at www.dotnetspark.com. Our aim is to help you pass your certification Exams (MCP, MCSD, MCAD etc.,) with flying scores and get good name in your company.

So, Start looking our Interview Question section daily and improve your .NET Skills. You can also help others by posting Interview Questions and their Answers in this section.

Hall of Fame    Twitter   Terms of Service    Privacy Policy    Contact Us    Archives   Tell A Friend