.

NET assembly
From Wikipedia, the free encyclopedia

For the counterpart to assembly language in the Microsoft .NET framework, see Common Intermediate Language. In the .NET framework, an assembly is a compiled code library used for deployment, versioning, and security. There are two types: process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process which will use classes defined in library assemblies. .NET assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at runtime by the CLR just-in-time compiler. An assembly can consist of one or more files. Code files are called modules. An assembly can contain more than one code module and since it is possible to use different languages to create code modules it is technically possible to use several different languages to create an assembly. Visual Studio however does not support using different languages in one assembly.
Contents [hide]

1 Assembly names 2 Assemblies versions 3 Assemblies and .NET security 4 Satellite assemblies 5 Referencing assemblies 6 Delay-signing of an assembly 7 Language of an assembly 8 References

[edit]Assembly

names

The name of an assembly consists of 4 parts:

1. The short name. On Windows this is the name of the Portable Executable file without the extension. 2. The culture. This is an RFC 1766 identifier of the locale for the assembly. In general, library and process assemblies should be culture neutral; the culture should only be used for satellite assemblies.

3. The version. This is a dotted number made up of 4 values major, minor, build and revision. 4. A public key token. This is a 64-bit hash of the public key which corresponds to the private key used to sign[1] the assembly. A signed assembly is said to have a strong name. The public key token is used to make the assembly name unique. Thus, two strong named assemblies can have the same PE file name and yet .NET will recognize them as different assemblies. The Windows file system (FAT32 and NTFS) only recognizes the PE file name, so two assemblies with the same PE file name (but different culture, version or public key token) cannot exist in the same Windows folder. To solve this issue .NET introduces the GAC (Global Assembly Cache) which is treated as a single folder by the .NET CLR, but is actually implemented using nested file system folders. To prevent spoofing attacks, where a cracker would try to pass off an assembly appearing as something else, the assembly is signed with a private key. The developer of the intended assembly keeps the private key secret, so a cracker cannot have access to it nor simply guess it. Thus the cracker cannot make his assembly impersonate something else, lacking the possibility to sign it correctly after the change. Signing the assembly involves taking a hash of important parts of the assembly and then encrypting the hash with the private key. The signed hash is stored in the assembly along with the public key. The public key will decrypt the signed hash. When the CLR loads a strongly named assembly it will generate a hash from the assembly and then compare this with the decrypted hash. If the comparison succeeds then it means that the public key in the file (and hence the public key token) is associated with the private key used to sign the assembly. This will mean that the public key in the assembly is the public key of the assembly publisher and hence a spoofing attack is thwarted. [edit]Assemblies

versions

.NET assemblies can have version information, allowing them to eliminate most conflicts between applications caused by shared assemblies[2]. However, this does not eliminate all possible versioning conflicts between assemblies[3]. [edit]Assemblies

and .NET security

.NET Code Access Security is based on assemblies and evidence. Evidence can be anything deduced from the assembly, but typically it is created from the source of the assembly whether the assembly was downloaded from the Internet, an intranet, or installed on the local machine (if the assembly is downloaded from another machine it will be stored in a sandboxed location within the GAC and hence is not treated as being installed locally). Permissions are applied to entire assemblies, and an assembly can specify the minimum permissions it requires through custom attributes (see .NET metadata). When the assembly is loaded the CLR will use the evidence for the assembly to create a

permission set of one or more code access permissions. The CLR will then check to make sure that this permission set contains the required permissions specified by the assembly. .NET code can perform a code access security demand. This means that the code will perform some privileged action only if all of the assemblies of all of the methods in the call stack have the specified permission. If one assembly does not have the permission a securityexception is thrown. The .NET code can also perform Linked Demand for getting the permission from the call stack. In this case the CLR will look at only one method in the call stack in the TOP position for the specified permission. Here the stack walk-through is bound to one method in the call stack by which the CLR assumes that all the other methods in the CALL STACK have the specified permission.This is known as assembly. The Assembly is a combination of METADATA and MSIL file. [edit]Satellite

assemblies

In general, assemblies should contain culture-neutral resources. If you want to localize your assembly (for example use different strings for different locales) you should use satellite assemblies special, resource-only assemblies. Satellites are not loaded by Fusion and so they should not contain code. As the name suggests, a satellite is associated with an assembly called the main assembly. That assembly (say, lib.dll) will contain the neutral resources (which Microsoft says is International English, but implies to be US English). Each satellite has the name of the associated library appended with .resources (for example lib.resources.dll). The satellite is given a non-neutral culture name, but since this is ignored by existing Windows file systems (FAT32 and NTFS) this would mean that there could be several files with the same PE name in one folder. Since this is not possible, satellites must be stored in subfolders under the application folder. For example, a satellite with the UK English resources will have a .NET name of "lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null", a PE file name of lib.resources.dll, and will be stored in a subfolder called enGB. Satellites are loaded by a .NET class called System.Resources.ResourceManager. The developer has to provide the name of the resource and information about the main assembly (with the neutral resources). The ResourceManager class will read the locale of the machine and use this information and the name of the main assembly to get the name of the satellite and the name of the subfolder that contains it. ResourceManager can then load the satellite and obtain the localized resource. [edit]Referencing

assemblies

One can reference an executable code library by using the /reference flag of the C# compiler.

[edit]Delay-signing

of an assembly

The shared assemblies need to give a strong name for uniquely identifying the assembly which might be shared among the applications. The strong naming consists of the public key token, culture, version and PE file name. If an assembly is likely to be used for the development purpose which is a shared assembly, the strong naming procedure contains only public key generation. The private key is not generated at that time. It is generated only when the assembly is deployed. [edit]Language

of an assembly

Main article: Common Intermediate Language The assembly is built up with the CIL code, which is an intermediate language. The framework internally converts the CIL [bytecode] into native assembly code. If we have a program that prints "Hello world", the equivalent CIL code for the method is:

.method private hidebysig static void Main(string[] args) cil managed { .entrypoint .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) // Code size 11 (0xb) .maxstack 1 IL_0000: ldstr "Hello World" IL_0005: call void [mscorlib]System.Console::WriteLine(string) IL_000a: ret } // end of method Class1::Main

So the CIL code loads the String onto the stack. Then it calls the Writeline function and returns.

What is a DLL?
A DLL is a library that contains code and data that can be used by more than one program at the same time. For example, in Windows operating systems, the Comdlg32 DLL performs common dialog box related functions. Therefore, each program can use the functionality that is contained in this DLL to implement an Open dialog box. This helps promote code reuse and efficient memory usage. By using a DLL, a program can be modularized into separate components. For example, an accounting program may be sold by module. Each module can be loaded into the main program at run time if that module is installed. Because the modules are separate, the load time of the program is faster, and a module is only loaded when that functionality is requested. Additionally, updates are easier to apply to each module without affecting other parts of the program. For example, you may have a payroll program, and the tax rates change each year. When these changes are isolated to a DLL, you can apply an update without needing to build or install the whole program again. The following list describes some of the files that are implemented as DLLs in Windows operating systems:

y y y

ActiveX Controls (.ocx) files An example of an ActiveX control is a calendar control that lets you select a date from a calendar. Control Panel (.cpl) files An example of a .cpl file is an item that is located in Control Panel. Each item is a specialized DLL. Device driver (.drv) files An example of a device driver is a printer driver that controls the printing to a printer.

Back to the top

DLL advantages
The following list describes some of the advantages that are provided when a program uses a DLL: Uses fewer resources When multiple programs use the same library of functions, a DLL can reduce the duplication of code that is loaded on the disk and in physical memory. This can greatly influence the performance of not just the program that is running in the foreground, but also other programs that are running on the Windows operating system.

Promotes modular architecture A DLL helps promote developing modular programs. This helps you develop large programs that require multiple language versions or a program that requires modular architecture. An example of a modular program is an accounting program that has many modules that can be dynamically loaded at run time.

Eases deployment and installation When a function within a DLL needs an update or a fix, the deployment and installation of the DLL does not require the program to be relinked with the DLL. Additionally, if multiple programs use the same DLL, the multiple programs will all benefit from the update or the fix. This issue may more frequently occur when you use a third-party DLL that is regularly updated or fixed.

Back to the top

DLL dependencies
When a program or a DLL uses a DLL function in another DLL, a dependency is created. Therefore, the program is no longer self-contained, and the program may experience problems if the dependency is broken. For example, the program may not run if one of the following actions occurs: A dependent DLL is upgraded to a new version. A dependent DLL is fixed. A dependent DLL is overwritten with an earlier version. A dependent DLL is removed from the computer.

y y y y

These actions are generally known as DLL conflicts. If backward compatibility is not enforced, the program may not successfully run. The following list describes the changes that have been introduced in Microsoft Windows 2000 and in later Windows operating systems to help minimize dependency issues: Windows File Protection In Windows File Protection, the operating system prevents system DLLs from being updated or deleted by an unauthorized agent. Therefore, when a program installation tries to remove or update a DLL that is defined as a system DLL, Windows File Protection will look for a valid digital signature.

Private DLLs Private DLLs let you isolate a program from changes that are made to shared DLLs. Private DLLs use version-specific information or an empty .local file to enforce the version of the DLL that is used by the

program. To use private DLLs, locate your DLLs in the program root folder. Then, for new programs, add version-specific information to the DLL. For old programs, use an empty .local file. Each method tells the operating system to use the private DLLs that are located in the program root folder. Back to the top

DLL troubleshooting tools

Several tools are available to help you troubleshoot DLL problems. The following tools are some of these tools. Dependency Walker The Dependency Walker tool can recursively scan for all dependent DLLs that are used by a program. When you open a program in Dependency Walker, Dependency Walker performs the following checks: Dependency Walker checks for missing DLLs. Dependency Walker checks for program files or DLLs that are not valid. Dependency Walker checks that import functions and export functions match. Dependency Walker checks for circular dependency errors. Dependency Walker checks for modules that are not valid because the modules are for a different operating system. By using Dependency Walker, you can document all the DLLs that a program uses. This may help prevent and correct DLL problems that may occur in the future. Dependency Walker is located in the following directory when you install Microsoft Visual Studio 6.0: drive\Program Files\Microsoft Visual Studio\Common\Tools DLL Universal Problem Solver The DLL Universal Problem Solver (DUPS) tool is used to audit, compare, document, and display DLL information. The following list describes the utilities that make up the DUPS tool: Dlister.exe This utility enumerates all the DLLs on the computer and logs the information to a text file or to a database file.

y y y y y

Dcomp.exe This utility compares the DLLs that are listed in two text files and produces a third text file that contains the differences.

Dtxt2DB.exe This utility loads the text files that are created by using the Dlister.exe utility and the Dcomp.exe utility into the dllHell database.

DlgDtxt2DB.exe This utility provides a graphical user interface (GUI) version of the Dtxt2DB.exe utility.

For more information about the DUPS tool, click the following article number to view the article in the Microsoft Knowledge Base: 247957 Using DUPS.exe to resolve DLL compatibility problems DLL Help database The DLL Help database helps you locate specific versions of DLLs that are installed by Microsoft software products. For more information about the DLL Help database, visit the following Microsoft Web site: http://support.microsoft.com/dllhelp/ Back to the top

DLL development

This section describes the issues and the requirements that you should consider when you develop your own DLLs. Types of DLLs When you load a DLL in an application, two methods of linking let you call the exported DLL functions. The two methods of linking are load-time dynamic linking and run-time dynamic linking. Load-time dynamic linking In load-time dynamic linking, an application makes explicit calls to exported DLL functions like local functions. To use load-time dynamic linking, provide a header (.h) file and an import library (.lib) file when you compile and link the application. When you do this, the linker will provide the system with the information that is required to load the DLL and resolve the exported DLL function locations at load time. Run-time dynamic linking In run-time dynamic linking, an application calls either the LoadLibrary function or theLoadLibraryEx function to load the DLL at run time. After the DLL is successfully loaded, you use the GetProcAddress function to obtain the address of the exported DLL function that you want to call. When you use run-time dynamic linking, you do not need an import library file. The following list describes the application criteria for when to use load-time dynamic linking and when to use runtime dynamic linking: Startup performance If the initial startup performance of the application is important, you should use run-time dynamic linking. Ease of use In load-time dynamic linking, the exported DLL functions are like local functions. This makes it easy for you to call these functions.

y y

Application logic In run-time dynamic linking, an application can branch to load different modules as required. This is important when you develop multiple-language versions.

The DLL entry point When you create a DLL, you can optionally specify an entry point function. The entry point function is called when processes or threads attach themselves to the DLL or detached themselves from the DLL. You can use the entry point function to initialize data structures or to destroy data structures as required by the DLL. Additionally, if the application is multithreaded, you can use thread local storage (TLS) to allocate memory that is private to each thread in the entry point function. The following code is an example of the DLL entry point function.

BOOL APIENTRY DllMain( HANDLE hModule, // Handle to DLL module DWORD ul_reason_for_call, // Reason for calling function LPVOID lpReserved ) // Reserved { switch ( ul_reason_for_call ) { case DLL_PROCESS_ATTACHED: // A process is loading the DLL. break; case DLL_THREAD_ATTACHED: // A process is creating a new thread. break; case DLL_THREAD_DETACH: // A thread exits normally. break; case DLL_PROCESS_DETACH:

// A process unloads the DLL. break; } return TRUE; }

When the entry point function returns a FALSE value, the application will not start if you are using load-time dynamic linking. If you are using run-time dynamic linking, only the individual DLL will not load. The entry point function should only perform simple initialization tasks and should not call any other DLL loading or termination functions. For example, in the entry point function, you should not directly or indirectly call the LoadLibrary function or the LoadLibraryEx function. Additionally, you should not call the FreeLibrary function when the process is terminating. Note In multithreaded applications, make sure that access to the DLL global data is synchronized (thread safe) to avoid possible data corruption. To do this, use TLS to provide unique data for each thread. Exporting DLL functions To export DLL functions, you can either add a function keyword to the exported DLL functions or create a module definition (.def) file that lists the exported DLL functions. To use a function keyword, you must declare each function that you want to export with the following keyword: __declspec(dllexport) To use exported DLL functions in the application, you must declare each function that you want to import with the following keyword: __declspec(dllimport) Typically, you would use one header file that has a define statement and an ifdef statement to separate the export statement and the import statement. You can also use a module definition file to declare exported DLL functions. When you use a module definition file, you do not have to add the function keyword to the exported DLL functions. In the module definition file, you declare the LIBRARY statement and the EXPORTSstatement for the DLL. The following code is an example of a definition file.

// SampleDLL.def // LIBRARY "sampleDLL" EXPORTS HelloWorld

Sample DLL and application In Microsoft Visual C++ 6.0, you can create a DLL by selecting either the Win32 Dynamic-Link Library project type or the MFC AppWizard (dll) project type. The following code is an example of a DLL that was created in Visual C++ by using the Win32 Dynamic-Link Library project type.

// SampleDLL.cpp // #include "stdafx.h" #define EXPORTING_DLL #include "sampleDLL.h" BOOL APIENTRY DllMain( HANDLE hModule,

DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } void HelloWorld() { MessageBox( NULL, TEXT("Hello World"), TEXT("In a DLL"), MB_OK); } // File: SampleDLL.h // #ifndef INDLL_H #define INDLL_H #ifdef EXPORTING_DLL extern __declspec(dllexport) void HelloWorld() ; #else extern __declspec(dllimport) void HelloWorld() ; #endif #endif
The following code is an example of a Win32 Application project that calls the exported DLL function in the SampleDLL DLL.

// SampleApp.cpp // #include "stdafx.h" #include "sampleDLL.h" int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { HelloWorld(); return 0; }
Note In load-time dynamic linking, you must link the SampleDLL.lib import library that is created when you build the SampleDLL project. In run-time dynamic linking, you use code that is similar to the following code to call the SampleDLL.dll exported DLL function.

... typedef VOID (*DLLPROC) (LPTSTR); ... HINSTANCE hinstDLL; DLLPROC HelloWorld; BOOL fFreeDLL; hinstDLL = LoadLibrary("sampleDLL.dll");

if (hinstDLL != NULL) { HelloWorld = (DLLPROC) GetProcAddress(hinstDLL, "HelloWorld"); if (HelloWorld != NULL) (HelloWorld); fFreeDLL = FreeLibrary(hinstDLL); } ...
When you compile and link the SampleDLL application, the Windows operating system searches for the SampleDLL DLL in the following locations in this order:

1.
2. 3.

The application folder The current folder The Windows system folder Note The GetSystemDirectory function returns the path of the Windows system folder.

4.

The Windows folder Note The GetWindowsDirectory function returns the path of the Windows folder.

Back to the top

The .NET Framework assembly

With the introduction of Microsoft .NET and the .NET Framework, most of the problems that are associated with DLLs have been eliminated by using assemblies. An assembly is a logical unit of functionality that runs under the control of the .NET common language runtime (CLR). An assembly physically exists as a .dll file or as an .exe file. However, internally an assembly is very different from a Microsoft Win32 DLL. An assembly file contains an assembly manifest, type metadata, Microsoft intermediate language (MSIL) code, and other resources. The assembly manifest contains the assembly metadata that provides all the information that is required for an assembly to be self-describing. The following information is included in the assembly manifest: Assembly name Version information Culture information Strong name information The assembly list of files Type reference information Referenced and dependent assembly information

y y y y y y y

The MSIL code that is contained in the assembly cannot be directly executed. Instead, MSIL code execution is managed through the CLR. By default, when you create an assembly, the assembly is private to the application. To create a shared assembly requires that you assign a strong name to the assembly and then publish the assembly in the global assembly cache. The following list describes some of the features of assemblies compared to the features of Win32 DLLs: Self-describing When you create an assembly, all the information that is required for the CLR to run the assembly is contained in the assembly manifest. The assembly manifest contains a list of the dependent assemblies. Therefore, the CLR can maintain a consistent set of assemblies that are used in the application. In Win32

DLLs, you cannot maintain consistency between a set of DLLs that are used in an application when you use shared DLLs.

Versioning In an assembly manifest, version information is recorded and enforced by the CLR. Additionally, version policies let you enforce version-specific usage. In Win32 DLLs, versioning cannot be enforced by the operating system. Instead, you must make sure that DLLs are backward compatible.

Side-by-side deployment Assemblies support side-by-side deployment. One application can use one version of an assembly, and another application can use a different version of an assembly. Starting in Windows 2000, side-by-side deployment is supported by locating DLLs in the application folder. Additionally, Windows File Protection prevents system DLLs from being overwritten or replaced by an unauthorized agent.

Self-containment and isolation An application that is developed by using an assembly can be self-contained and isolated from other applications that are running on the computer. This feature helps you create zero-impact installations.

Execution An assembly is run under the security permissions that are supplied in the assembly manifest and that are controlled by the CLR.

Language independent An assembly can be developed by using any one of the supported .NET languages. For example, you can develop an assembly in Microsoft Visual C#, and then use the assembly in a Microsoft Visual Basic .NET project.