Assembly

Assembly (CLI)

An assembly in the Common Language Infrastructure (CLI) 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 that will use classes defined in library assemblies. CLI assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at run time by the just-in-time compiler. In the .NET Framework implementation, this compiler is part of the Common Language Runtime (CLR).

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.

Assembly names[edit]

The name of an assembly consists of four parts

1.    The short name. On Windows this is the name of the Portable Executable (PE) 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 four values — major, minor, build and revision.

4.    A public key token. This is a 64-bit hash of the public key that 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 the CLI 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 the CLI introduces the GAC (Global Assembly Cache) that is treated as a single folder by run-time, 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 prevented.

Assembly versions[edit]

CLI 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]

Assemblies and CLI security[edit]

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

CLI 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 security exception is thrown.

The CLI 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. The Assembly is a combination of METADATA and MSIL file.

Satellite assemblies[edit]

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. 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 (that 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 CLI 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 en-GB.

Satellites are loaded by a CLI 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.

Referencing assemblies[edit]

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

Delay-signing of an assembly[edit]

The shared assemblies need to give a strong name for uniquely identifying the assembly that 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.

Language of an assembly[edit]

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.

Dynamic-Link Libraries

http://msdn.microsoft.com/en-us/library/ms681914(v=vs.85).aspx

SpecificVersion=false

Dynamic linking allows a module to include only the information needed to locate an exported DLL function at load time or run time. Dynamic linking differs from the more familiar static linking, in which the linker copies a library function's code into each module that calls it.

Types of Dynamic Linking

There are two methods for calling a function in a DLL:

• In load-time dynamic linking, a module makes explicit calls to exported DLL functions as if they were local functions. This requires you to link the module with the import library for the DLL that contains the functions. An import library supplies the system with the information needed to load the DLL and locate the exported DLL functions when the application is loaded.
• In run-time dynamic linking, a module uses the LoadLibrary or LoadLibraryEx function to load the DLL at run time. After the DLL is loaded, the module calls theGetProcAddress function to get the addresses of the exported DLL functions. The module calls the exported DLL functions using the function pointers returned byGetProcAddress. This eliminates the need for an import library.

DLLs and Memory Management

Every process that loads the DLL maps it into its virtual address space. After the process loads the DLL into its virtual address, it can call the exported DLL functions.

The system maintains a per-process reference count for each DLL. When a thread loads the DLL, the reference count is incremented by one. When the process terminates, or when the reference count becomes zero (run-time dynamic linking only), the DLL is unloaded from the virtual address space of the process.

Like any other function, an exported DLL function runs in the context of the thread that calls it. Therefore, the following conditions apply:

• The threads of the process that called the DLL can use handles opened by a DLL function. Similarly, handles opened by any thread of the calling process can be used in the DLL function.
• The DLL uses the stack of the calling thread and the virtual address space of the calling process.
• The DLL allocates memory from the virtual address space of the calling process.

For more information about DLLs, see the following topics:

• Advantages of Dynamic Linking
• Dynamic-Link Library Creation
• Dynamic-Link Library Entry-Point Function
• Load-Time Dynamic Linking
• Run-Time Dynamic Linking
• Dynamic-Link Library Search Order
• Dynamic-Link Library Data
• Dynamic-Link Library Redirection
• Dynamic-Link Library Updates
• Dynamic-Link Library Security
• AppInit DLLs and Secure Boot

Visual Basic Concepts - Creating, Running, and Distributing Executable (.EXE) Files

To run your application under Microsoft Windows outside of Visual Basic, you need to create an executable (.exe) file. You create executable files for applications that use ActiveX controls the same as you would for any other application. There are a few issues to consider, however, when running such an application.

Visual Basic Executable (.exe) Files

An ActiveX control file is accessed both by Visual Basic and by applications created with Visual Basic. When you run an executable file that contains an ActiveX control, the .ocx file associated with it must be registered in the system registry. Otherwise, the application will not be able to find the code needed to create the control.

If a control cannot be found, the Visual Basic run-time DLL generates the error message "File Not Found." If you want to distribute an application that uses ActiveX controls, it is recommended that your installation procedure copy all required .ocx files into the user's \Windows\System directory. Your installation procedure should also register the required controls in the system registry.

You can freely distribute any application you create with the Visual Basic to any Microsoft Windows user. The Package and Deployment Wizard included with Visual Basic provides tools to help you write setup programs that install your application. Users will need copies of the following:

• The Visual Basic run-time file.
• Any .ocx files.
• Additional DLLs, as required by your application or by ActiveX controls.

ActiveX control

ActiveX is a software framework created by Microsoft which adapts its earlier Component Object Model (COM) and Object Linking and Embedding (OLE) technologies for content downloaded from a network, particularly in the context of the World Wide Web.^[1] It was introduced 1996 and is commonly used in itsWindows operating system. In principle it is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator. Most also require the client to be running on Intel x86 hardware, because they contain compiled code.^[2]

Many Microsoft Windows applications — including many of those from Microsoft itself, such as Internet Explorer, Microsoft Office, Microsoft Visual Studio, andWindows Media Player — use ActiveX controls to build their feature-set and also encapsulate their own functionality as ActiveX controls which can then be embedded into other applications. Internet Explorer also allows the embedding of ActiveX controls in web pages.

However, ActiveX will not work on all platforms, so using ActiveX controls to implement essential functionality of a web page restricts its usefulness.

History[edit]

Faced with the complexity of OLE 2.0 and with poor support for COM in MFC, Microsoft simplified the specification and rebranded the technology as ActiveX in 1996.^[3][4] Even after simplification, users still required controls to implement about six core interfaces. In response to this complexity, Microsoft produced wizards, ATL base classes, macros and C++ language extensions to make it simpler to write controls.

Starting with Internet Explorer 3.0 (1996), Microsoft added support to host ActiveX controls within HTML content. If the browser encountered a page specifying an ActiveX control via an OBJECT tag, it would automatically download and install the control with little or no user intervention. This made the web "richer" but provoked objections (since such controls ran only on Windows) and security risks (especially given the lack of user intervention). Microsoft subsequently introduced security measures to make browsing including ActiveX safer.^[5]

For example:

·        digital signing of installation packages (Cabinet files and executables)

·        controls must explicitly declare themselves safe for scripting

·        increasingly stringent default security settings

·        Internet Explorer maintains a blacklist of bad controls

On 17 October 1996, Microsoft announced availability of the beta release of the Microsoft ActiveX Software Development Kit (SDK) for the Macintosh.^[6]

Shortly thereafter, Microsoft made ActiveX open source. Documentation for ActiveX core technology resides at The Open Group and may be downloaded for free.^[7]

ActiveX control is a control using Microsoft ActiveX technologies. An ActiveX control can be automatically downloaded and executed by aWeb browser. ActiveX is not a programming language, but rather a set of rules for how applications should share information.

Programmers can develop ActiveX controls in a variety of languages, including C, C++, Visual Basic, and Java.

An ActiveX control is similar to a Java applet. Unlike Java applets, however, ActiveX controls have full access to the Windows operating system. This gives them much more power than Java applets, but with this power comes a certain risk that the applet may damage software or data on your machine. To control this risk, Microsoft developed a registration system so that browsers can identify andauthenticate an ActiveX control before downloading it. Another difference between Java applets and ActiveX controls is that Java applets can be written to run on all platforms, whereas ActiveX controls are currently limited to Windows environments.

Manifest (CLI)

An assembly manifest is a text file containing metadata about CLI assemblies. It describes the relationship and dependencies of the components in the assembly, versioning information, scope information and the security permissions required by the assembly.

The manifest information embedded within an assembly can be viewed using IL Disassembler (ILDASM.exe) which is available as part of Microsoft Windows SDK.

Assembly manifest[edit]

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.

The following illustration shows the different ways the manifest can be stored.

Types of assemblies[edit]

For an assembly with one associated file, the manifest is incorporated into the PE (Portable Executable) file to form a single-file assembly. You can create a multifile assembly with a standalone manifest file or with the manifest incorporated into one of the PE files in the assembly.

Each assembly's manifest performs the following functions:

·        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 manifest contents[edit]

The following table shows the information contained in the assembly manifest. The first four items — the assembly name, version number, culture, and strong name information — make up the assembly's identity.

Manifest contents
Assembly name	A text string specifying the assembly's name.
Version number	A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.
Culture	Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or language-specific information. (An assembly with culture information is automatically assumed to be a satellite assembly.)
Strong name information	The public key from the publisher if the assembly has been given a strong name.
List of all files in the assembly	A hash of each file contained in the assembly and a file name. Note that all files that make up the assembly must be in the same directory as the file containing the assembly manifest.
Type reference information	Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.
Information on referenced assemblies	A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.