Appendix F. Glossary

ActiveX Assembly

An assembly created by the ActiveX importer that contains .NET class definitions for ActiveX controls. An ActiveX Assembly references an Interop Assembly containing the “raw” type definitions.

See Also Interop Assembly.

ActiveX importer

Also called the “.NET ActiveX Control to Windows Forms Assembly Generator”, the ActiveX importer generates an ActiveX Assembly (and possibly the referenced Interop Assembly) from a type library. This functionality is exposed when using a COM component from the toolbox in Visual Studio .NET, or by using the AXIMP.EXE SDK tool.

See Also type library exporter.

apartment

In COM, an apartment is a logical process that contains objects with similar threading requirements. A single-threaded apartment (STA) only has one thread, a multi-threaded apartment (MTA) can contain multiple threads, and a neutral apartment (NA) contains no threads.

application domain

Often abbreviated as AppDomain, it is a lightweight logical container managed by the CLR. It provides the same sort of isolation as an operating system process, but multiple application domains may exist in a single process.

ASP Compatibility Mode

An ASP.NET setting that provides backwards-compatible behavior with ASP. The main use of this is to use STA threads rather than the default MTA threads used by ASP.NET.

See Also MTA Thread, STA Thread.

assembly

An assembly is the unit of deployment and versioning in the .NET Framework. An assembly contains a manifest, metadata, MSIL, and possibly binary resources. Most assemblies are single files, but an assembly can consist of multiple files, such as DLLs, picture files, and even HTML files.

See Also manifest, metadata, MSIL.

binary compatibility

Indicates that one COM object can be replaced with another without affecting existing COM clients. This can occur when they have the same CLSID and ProgID, when they both implement the same interfaces, and when they both source the same interfaces. By doing this, their binary specifications are equivalent.

blittable

A blittable data type is one that has the same managed and unmanaged representations. For such data types, the Interop Marshaler pins an instance and exposes it directly to unmanaged code rather than performing a slower copy operation. This performance optimization is not possible for non-blittable types, since one representation must always be copied to the other representation. See Chapter 3, “The Essentials for Using COM in Managed Code,” for a list of blittable types.

C-style array

A C-style array is any array type that is simply a pointer to the first element in a list of contiguous elements. The user of such an array must always know its length, otherwise she can easily access meaningless memory. C-style arrays in a type library do not work well with COM Interoperability, and do not have the same self-describing qualities as a COM SAFEARRAY or a .NET array.

CCW

See COM-Callable Wrapper.

class interface

A class interface can be exposed by a COM-Callable Wrapper for a .NET class. Such an interface exposes all the COM-visible members of the .NET class and its base classes. By default, .NET classes have an auto-dispatch class interface exposed, meaning that COM clients can only late bind to members not explicitly exposed on an interface. This is the safest option for versioning, but an auto-dual class interface can be exposed instead, or a class interface can be suppressed altogether.

CLR

See Common Language Runtime.

CLS

See Common Language Specification.

CLSID

See GUID.

coclass interface

A coclass interface is an interface produced by the type library importer that has the same name as a coclass in the input type library. A coclass interface derives from the coclass’s default interface and possibly an importer-generated event interface. Coclass interfaces are marked with the CoClassAttribute custom attribute so languages like C# and VB .NET can enable users to instantiate the interface type as if it’s a class type.

COM-Callable Wrapper

A COM-Callable Wrapper (CCW) is a COM object that acts as a proxy for a .NET object. The wrapper forwards calls to the .NET object through its exposed interfaces, enabling .NET-unaware COM objects to use .NET objects in a natural way.

COM marshaling

Marshaling between COM contexts (apartments, processes, or threads). This is the same sort of marshaling that can occur in COM and is unrelated to the .NET Framework. COM components, such as those authored in Visual Basic 6, often use type library marshaling to accomplish COM marshaling, but it could also be done with a MIDL-generated proxy/stub DLL or in a custom fashion.

See Also type library marshaling, Interop marshaling.

COM Interoperability

The technology that enables COM components to be used in .NET and .NET components to be used in COM.

COM visibility

Indicates whether a .NET type or member is accessible from COM. Anything public in .NET is visible to COM unless it’s marked with the ComVisibleAttribute custom attribute with its argument set to false, or its containing assembly is marked with the attribute with its argument set to false.

Common Language Runtime

The execution engine or “kernel” of the .NET Framework.

Common Language Specification

A subset of language features that should be supported by .NET languages and tools, to enable cross-language interoperability.

connectable object

A COM object that exposes connection points to provide event-like behavior.

custom attribute

A class that can be marked on elements like assemblies, types, members, parameters, and so on, to mark them with custom information. Often simply referred to as “attributes,” custom attributes enable arbitrary extensibility of metadata. The .NET Framework makes heavy use of custom attributes to provide semantics that can’t be expressed in standard metadata alone.

See Also pseudo-custom attribute.

custom marshaling

In COM Interoperability, custom marshaling refers to using an object that implements System.Runtime.InteropServices.ICustomMarshaler that can replace the standard Interop Marshaler when marshaling between managed and unmanaged code is performed.

See Also Interop Marshaler, Interop marshaling.

default constructor

A constructor with no parameters. .NET classes must have a public default constructor in order to be instantiated from COM.

default interface

A coclass’s interface marked with [default] in a type library, or the first interface listed if none are marked with the attribute. Default interfaces are important when importing a type library since every coclass interface inherits the members of the default interface (but no other implemented interfaces), and parameters or fields of the default interface type may be substituted with the coclass interface type.

delegate

A .NET class representing a method signature that can be used like a type-safe function pointer. .NET applications use delegates for callback functionality.

DISPID

Short for dispatch identifier, a DISPID is a number assigned to a member of a dual or dispinterface that is passed to IDispatch.Invoke in order to call it. Each member’s parameter can also have a DISPID in order to support invocation using named parameters.

dispinterface

A COM interface whose members can only be accessed via the members of IDispatch. This is the only type of interface for which COM users don’t depend on the layout of its members.

dual interface

A COM interface that derives from IDispatch but also exposes its methods for v-table access.

formatted class

A formatted class is a .NET class that has structure layout. This means that it’s marked with StructLayoutAttribute and either LayoutKind.Sequential or LayoutKind.Explicit. Such a class is treated like a value type would be when exposed to unmanaged code.

formatted reference type

See formatted class.

garbage collection

The act of freeing unused memory (“garbage”) whenever appropriate so the users who allocate memory aren’t responsible for freeing it themselves. Objects that don’t release limited resources until destruction can cause problems in a garbage collection environment, since the garbage collector is unaware of the need to release such an object in a timely fashion unless available memory is low.

Global Assembly Cache

A central storage location for strong-named assemblies that are meant to be shared by multiple applications. The Global Assembly Cache (GAC) and its assembly-loading rules are the key to side-by-side installation and execution of assemblies. By default, the Global Assembly Cache resides in the Assembly subdirectory of your Windows folder.

See Also assembly.

GUID

A 128-bit globally unique identifier, sometimes called a universally unique identifier (UUID). The CoCreateGuid Windows API (exposed as the System.Guid.NewGuid method in the .NET Framework) can generate GUIDs that are highly likely to be unique. GUIDs are used in COM to provide unique identity to elements such as classes, interfaces, and type libraries. A GUID used to identify a class is called a CLSID (Class Identifier), a GUID used to identify an interface is called an IID (Interface Identifier), and so on.

HRESULT

A 32-bit status code used to convey errors, warnings, or success. Almost all COM members return HRESULTs.

IDispatch

A COM interface implemented by most COM objects in order to provide late bound access to its members.

IDL

See Interface Definition Language.

IID

See GUID.

IL Assembler

The IL Assembler is a utility that is installed with the .NET Framework SDK with the filename ILASM.EXE. With it, you can convert source code in a language typically called IL Assembler into an assembly. IL Assembler can be viewed as just another .NET language and compiler like C# or Visual Basic .NET, but at a much lower level. Source files used as input for the IL Assembler usually have a .il extension and often originate from files created by the IL Disassembler. This is useful for making changes to an existing assembly by disassembling it, changing the output text file, then re-assembling it, as demonstrated in Chapter 7, “Modifying Interop Assemblies.”

See Also IL Disassembler, metadata, MSIL.

IL Disassembler

The IL Disassembler is a utility that is installed with the .NET Framework SDK with the filename ILDASM.EXE. With it, you can browse any assembly’s metadata and view each member’s IL implementation. By default, it runs as a graphical application, but with command-line options it can do additional tasks such as outputting a text file that can be consumed by the IL Assembler.

See Also IL Disassembler, metadata, MSIL.

Interface Definition Language

Interface Definition Language (IDL) is a language used to define COM types, typically compiled with MIDL.

See Also MIDL.

Intermediate Language

See MSIL.

Interop Assembly

An assembly, usually produced by the type library importer, that contains definitions of COM types described in metadata. Authors of COM components should create a Primary Interop Assembly to prevent duplicate, non-compatible Interop Assemblies from becoming prevalent.

See Also Primary Interop Assembly.

Interop Marshaler

A marshaler built-into the CLR that performs the transformations between managed and unmanaged data types. The same marshaler is used for COM Interoperability and for PInvoke, although its default behavior can change depending on the context in which it is used. The Interop Marshaler is not general-purpose, but can be customized using custom attributes such as MarshalAsAttribute, InAttribute, and OutAttribute.

See Also Interop marshaling.

Interop marshaling

The process of converting managed data types to unmanaged data types and vice-versa. Interop marshaling is only done when crossing the managed/unmanaged boundary, and does not take the place of COM marshaling.

See Also COM marshaling.

IUnknown

A COM interface that must be implemented by an object for it to be considered a COM object. IUnknown provides methods for reference counting and for obtaining other interfaces implemented by the object.

JUMP to .NET

The Java User Migration Path to .NET is a collection of technologies, including Visual J# .NET, for migrating and interoperating with existing unmanaged Java components. Java developers are best served by using these technologies rather than using COM Interoperability to use Java-COM components from .NET.

link demand

A .NET security check that occurs during just-in-time compilation and only checks the immediate caller of the member marked with the demand. Members marked with link demands can execute faster than those marked with regular demands because a full stack walk to check every caller’s permissions is avoided. Such code is susceptible to luring attacks, however, so great care must be used with them.

managed code

Managed code is code that requires the execution environment of the Common Language Runtime. Compilers emit managed code as IL and metadata. The reason for the name is that the code is managed by the CLR and objects are allocated from a heap managed by the CLR.

See Also unmanaged code.

manifest

The part of an assembly that describes it identity, lists the files it is comprised of, lists the dependencies on other assemblies, and contains other information such as its required permission set. Every assembly has one manifest, regardless of how many files it contains. The file with the embedded manifest is the one that must be used with tools such as REGASM.EXE or APIs such as Assembly.LoadFrom.

marshaling

The act of translating data from one representation to another. The Interop Marshaler performs marshaling of managed data types to unmanaged data types, whereas COM marshaling refers to translating data from one context (apartment, process, or thread) to another.

See Also Interop Marshaler, Interop marshaling, COM marshaling.

metadata

Information inside an assembly that describes its types. Metadata is required by .NET compilers for binding, required by the CLR for many of its services, and used by object browsers and IntelliSense to provide a rich programming experience. Metadata is the .NET version of COM type information (as found in a type library), but much more expressive.

MIDL

MIDL stands for Microsoft IDL Compiler. It compiles an IDL file and can produce a proxy/stub DLL required for COM marshaling, and/or a type library.

See Also COM marshaling, type library.

MSIL

MSIL, sometimes abbreviated as just IL, is short for Microsoft Intermediate Language. MSIL is produced by any .NET compiler, and is the language of .NET. At run time, the .NET just-in-time (JIT) compiler converts MSIL into assembly code that’s native to the current computer’s processor. Since assemblies contain their source code in the form of MSIL (except for mixed-mode C++ assemblies, which also contain unmanaged code), they can be used on any platform with an appropriate JIT compiler without being recompiled from its original source code.

MTA Thread

A thread that runs inside a multi-threaded apartment (MTA).

See Also apartment.

Names file

A file that can be used with the type library exporter (TLBEXP.EXE) and its /names option in order to control the case of exported identifiers.

See Also type library exporter.

pinning

Holding a .NET object in a fixed location in memory, preventing it from being moved or collected by the .NET garbage collector. Any .NET objects whose memory is exposed directly to unmanaged code must be pinned, because the garbage collector is free to move objects in memory at any time otherwise. Pinning should be done as little as possible and for short amounts of time, because it interferes with the garbage collector and may prevent it from executing optimally.

PInvoke

See Platform Invocation Services.

Platform Invocation Services

The technology that enables calling unmanaged DLL entry points directly from managed code, and enables callbacks into managed code. Platform Invocation Services is commonly called PInvoke or Platform Invoke.

Primary Interop Assembly

An assembly containing definitions of COM types that is distributed and digitally signed by the author of the COM component. Visual Studio .NET transparently uses a registered Primary Interop Assembly when a user references its corresponding type library. Primary Interop Assemblies are important because multiple definitions of the same COM types in separate assemblies are treated as unrelated types in .NET.

See Also Interop Assembly.

pseudo-custom attribute

Bits in metadata that are set in source code using custom attribute syntax. Pseudo-custom attributes seem no different than real custom attributes to the programmer marking their code, but they are persisted in metadata differently. The same abstraction is not maintained in reflection, for which pseudo-custom attributes are not discoverable as custom attributes. Instead, some pseudo-custom attribute data can be obtained using specific APIs, whereas other data cannot be obtained from reflection alone. Examples of pseudo-custom attributes discussed in this book are ComImportAttribute, DllImportAttribute, and MarshalAsAttribute.

See Also custom attribute.

RCW

See Runtime-Callable Wrapper.

reference type

A data type that is always passed as a reference to the actual instance on the managed heap. In C++ terms, reference types always have an implied pointer. Reference types (except for strings and usually arrays) are marshaled to unmanaged code as interface pointers unless they are marked with sequential or explicit layout using the StructLayoutAttribute pseudo-custom attribute.

reflection

The technology that enables the discovery of .NET type information at run time, and dynamic invocation.

Runtime-Callable Wrapper

A Runtime-Callable Wrapper (RCW) is a .NET object that acts as a proxy for a COM object. The wrapper, which is a System.__ComObject or derived type, forwards calls to the COM object through its exposed interfaces and handles COM tasks such as reference counting.

SAFEARRAY

The self-describing array type used in COM. Arrays in Visual Basic 6 are SAFEARRAYs.

source interface

An interface listed by a coclass that it can call back upon to support event-like behavior in COM. The coclass listing a source interface does not implement it. Objects that implement the interface can “register” themselves with the coclass using the COM connection point interfaces.

STA Thread

A thread that runs inside a single-threaded apartment (STA).

See Also apartment.

strong name

An assembly name that includes a public key, sometimes called a shared name. Strong named assemblies have unique names by virtue of the public key information.

type library

A binary file containing type information of COM types; the COM version of metadata. The MIDL compiler creates type libraries from IDL files, and Visual Basic 6 creates type libraries from source code. A type library can be a standalone file (usually with a .tlb extension) or embedded as a resource in any other file, like a DLL.

See Also MIDL.

type library importer

Creates an Interop Assembly from a type library. This functionality is exposed when referencing a type library in Visual Studio .NET, or when using the TLBIMP.EXE SDK tool.

See Also Interop Assembly, Primary Interop Assembly.

type library exporter

Creates a type library from an assembly. This functionality is exposed when using the Register for COM Interop option in Visual Studio .NET, or when using the TLBEXP.EXE SDK tool.

type library marshaling

COM marshaling done by the OLE Automation marshaler, which uses a registered type library to determine how to marshal the types.

UDT

See user-defined type.

unmanaged code

Unmanaged code is code that does not use or require the execution environment of the Common Language Runtime. Unmanaged code is outside of the reach of the CLR’s security system, garbage collector, and other services.

See Also managed code.

unmanaged code permission

The common term used to describe SecurityPermissionFlag.UnmanagedCode, a flag that is a part of SecurityPermission (in the System.Security.Permissions namespace). Unmanaged code can only be called and run by a .NET application if the application has been granted unmanaged code permission. Due to the nature of unmanaged code, this permission effectively means full trust.

See Also unmanaged code.

unsafe code

A feature in the C# language that lets you use pointers like in C++. Such code must be used in an unsafe block, but it’s not really “unsafe” to use these features correctly; the term refers to the fact that the CLR can’t prove the safety of such code. Also, manipulating pointers can easily lead to buggy code. The use of this feature requires unmanaged code permission since direct manipulation of memory isn’t verifiably type safe and could enable a malicious programmer to access resources that would otherwise have been blocked by code access security.

user-defined type

A user-defined type (UDT) is a name typically given to a structure in COM or a value type in .NET.

v-table

Short for virtual function table, a v-table is a table of virtual function pointers. This binary structure forms the basis of COM interfaces.

value type

A data type that is a value on the stack, rather than an object on a garbage-collected heap. Value types are marshaled to unmanaged code as structures.

VARIANT

A common COM data type that serves a similar role as .NET’s System.Object type. A VARIANT is a structure that can contain any primitive type or a pointer to an interface pointer or UDT. It has a vt field that describes what kind of type is contained within, set to a constant such as VT_BSTR, VT_DECIMAL, or VT_I4.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset