ASSEMBLY. A SSEMBLY Assemblies are the fundamental units of applications in the.net framework An assembly can contain classes, structures, interfaces.

ASSEMBLY

ASSEMBLY Assemblies are the fundamental units of

applications in the .net framework An assembly can contain classes, structures,

interfaces and resources that an application requires

The compiler translates the source code into the Intermediate language(IL) code

In addition to translating the code into IL, the compiler also produces metadata about the program

It also contains an assembly manifest that contains the assembly metadata

THE ASSEMBLY MANIFEST

Every assembly contains an assembly manifest, a set of metadata with information about the assembly. The assembly manifest contains these items: The assembly name and version The culture or language the assembly supports

(not required in all assemblies) The public key for any strong name assigned to the

assembly (not required in all assemblies) A list of files in the assembly with hash information Information on referenced assemblies

In addition, you can add other information to the manifest by using assembly attributes.

METADATA

Metadata is data about data Metadata describes every type and member

defined in your code in a Multilanguage form

METADATA IN ASSEMBLY

Type Descriptions

ClassesBase classesImplemented interfacesData membersMethods

NameVersionCulture

Assembly Description

Other assembliesSecurity PermissionsExported Types

ASSEMBLIES An Assembly is the managed equivalent of

an EXE / DLL Smallest deployable unit in the CLR Have unique version number No version conflicts(known as DLL hell) Contains IL code to be executed Security boundary-permissions are granted

at the assembly level Type boundary-all types include the assembly

name they are a part of Self-describing manifest—metadata that

describes the types in the assembly

ASSEMBLIES All .NET programs are constructed from these

Assemblies. Assemblies are made of two parts:  manifest, contains information about what

is contained within the assembly modules, internal files of IL code which are

ready to run and metadata. When programming, we don't directly deal

with assemblies as the CLR and the .NET framework takes care of that behind the scenes.

Self-Describing It contains all information about the types

(classes) contained in the assembly, all external references needed for executing the assembly and so on.

This is possible with an assembly manifest Assemblies can be viewed by application

developers with the help of a tool called ildasm (IL Disassembler) provided by the .NET Framework.

TYPES OF ASSEMBLIES

Assemblies can be private or shared. The assembly which is used by a single

application is called as private assembly. Suppose we have created a DLL which

encapsulates business logic. This DLL is used by the client application only and not by any other application.

STEPS TO CREATE PRIVATE ASSEMBLY

Create a ClassLibrary. Then afterwards build it. After building, .dll is created.

Now we can find that really, .dll file has been created in the bin\Debug folder. Now we want to use this .dll in our new Widows Form Application.

Now I have created one New Windows Form Application. Add the .dll by Add Reference->Browse. And as we can see, select the required.dll

Separate copy of ClassLibrary1.dll has been copied here in Windows Form Application. So this is Private Assembly.

SHARED ASSEMBLIES

To make a shared assembly, we require it to store in Global Assembly Cache GAC. GAC is reserved for storing assemblies and for sharing them in between different applications.

Here every assembly must have an unique name. So we need to assign strong name to assemblies before storing it in the GAC.

PICTORIAL REPRESENTATION OF SHARED ASSEMBLY

GAC(shared

assembly)

Application1

Application2

Application3

Application4

ADDING .DLL IN THE GAC

LOCATION OF SHARED ASSEMBLY

Here our shared assembly is located.

Here no separate copy of assembly is pasted in the WindowApplication3\bin\debug folder. Instead here the shared assembly from the GAC has been used.

WHAT IS GLOBAL ASSEMBLY CACHE?

An assembly that is shared by multiple applications is called a global assembly and is installed in the global assembly cache (GAC).

Global assembly cache is nothing but a special disk folder where all the shared assemblies are kept.

It is located under C:\Windows\Microsoft.NET \assembly\GAC_MSIL folder on every machine running the .NET framework.

BENEFITS OF PRIVATE ASSEMBLIES

Private assemblies are installed in a directory named bin\Debug located under the application directory. These files are private to the application.

It is great for small utility Assemblies/ application specific code

DISADVANTAGE

When you have multiple applications using one assembly, you have to deploy the assembly to the bin directory of each application.

The .NET Framework uses assemblies as the fundamental unit for several purposes:

Security Type Identity Reference Scope Versioning Deployment

SECURITY

An assembly is the unit at which security permissions are requested and granted. Assemblies are also the level at which you establish identity and trust.

The .NET Framework provides two mechanisms for this level of assembly security: strong names and Signcode.exe. You can also manage security by specifying the level of trust for code from a particular site or zone.

Signing an assembly with a strong name adds public key encryption to the assembly.

This ensures name uniqueness and prevents substituting another assembly with the same name for the assembly that you provided.

SECURITY

The signcode.exe tool embeds a digital certificate in the assembly. This allows users of the assembly to verify the identity of the assembly's developer by using a public or private trust hierarchy.

You can choose to use either strong names, Signcode.exe, or both, to strengthen the identity of your assembly.

The common language runtime also uses internal hashing information, in conjunction with strong names and signcode, to verify that the assembly being loaded has not been altered after it was built.

TYPE IDENTITY

The identity of a type depends on the assembly where that type is defined.

That is, if you define a type named DataStore in one assembly, and a type named DataStore in another assembly, the .NET Framework can tell them apart because they are in two different assemblies.

Of course you can't define two different types with the same name in the same assembly.

REFERENCE SCOPE

The assembly is also the location of reference information in general. Each assembly contains information on references in two directions:

The assembly contains metadata that specifies the types and resources within the assembly that are exposed to code outside of the assembly. For example, a particular assembly could expose

a public type named Customer with a public property named AccountBalance.

The assembly contains metadata specifying the other assemblies on which it depends. For example, a particular assembly might specify

that it depends on the System.Windows.Forms.dll assembly.

VERSIONING

Each assembly has a 128-bit version number that is presented as a set of four decimal pieces: Major.Minor.Build.Revision

For example, an assembly might have the version number 3.5.0.126.

By default, an assembly will only use types from the exact same assembly (name and version number) that it was built and tested with.

DEPLOYMENT

Assemblies are the natural unit of deployment.

You can also deploy assemblies in other ways, including by a simple xcopy to the target system or via code download from a web site.

When you start an application, it loads other assemblies as a unit as types and resources from those assemblies are needed.