Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication and dynamic object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime.
When a variable is declared using one of the basic, built-in data types or a structure, it is a value type. An exception is the string data type, which is a reference type.
A value type stores its contents in memory allocated on the stack. Using the stack is efficient, but the limited lifetime of value types makes them less suited for sharing data between different classes.
A value type is derived from System.ValueType. It can't be used as base class.
In contrast, a reference type, such as an instance of a class or an array, is allocated in a different area of memory - the heap.
It's only reclaimed when C#'s garbage collection system determines it
is no longer needed.
int numbers = new int;
In c++, the value and reference is determined by class user;
In c#, it is determined by class definer.
Delegate and Events
Delegation is like function pointer in C++, but is type-safe. Events is based on delegation.
The C# "using" statement results in a call to Dispose(). This is the same as Close(), which may throw exceptions when a network error occurs. The call to Dispose() happens implicitly at the closing brace of the "using" block.
User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the applications. The applications try to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM account or the IWAM_[servername] accounts). Therefore, Office may not initialize correctly on startup. In this situation, Office returns an error on the CreateObject function or the CoCreateInstance function. Even if the Office application can be started, other functions may not work correctly if no user profile exists.
Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some circumstances, applications may need to be made visible for certain Automation functions to work correctly. If an unexpected error occurs, or if an unspecified parameter is needed to complete a function, Office is designed to prompt the user with a modal dialog box that asks the user what the user wants to do. A modal dialog box on a non-interactive desktop cannot be dismissed. Therefore, that thread stops responding (hangs) indefinitely. This fact alone makes running Office Applications from a server-side environment risky and unsupported.
Reentrancy and scalability: Server-side components need to be highly reentrant, multi-threaded COM components that have minimum overhead and high throughput for multiple clients. Office applications are in almost all respects the exact opposite. Office applications are non-reentrant, STA-based Automation servers that are designed to provide diverse but resource-intensive functionality for a single client. The applications offer little scalability as a server-side solution. Additionally, the applications have fixed limits to important elements, such as memory. These cannot be changed through configuration.
Resiliency and stability: Office 2000, Office XP, Office 2003, and Office 2007 use Microsoft Windows Installer (MSI) technology to make installation and self-repair easier for an end user. MSI introduces the concept of "install on first use." This allows features to be dynamically installed or configured at run time for the system, or more often for a particular user. In a server-side environment, this both slows down performance and increases the likelihood that a dialog box may appear that asks the user to approve the installation or to provide an installation disk. Although this is designed to increase the resiliency of Office as an end-user product, Office's implementation of MSI capabilities is counterproductive in a server-side environment.
Server-side security. Do not open files that are uploaded to the server from an anonymous Web site. Based on the security settings that were last set, the server can run macros under an Administrator or System context with full privileges and can therefore compromise your network.
Licensing issues. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
Alternatives to server-side Automation:
Most server-side Automation tasks involve document creation or editing. Office 2007 supports new Open XML file formats that let developers create, edit, read, and transform file content on the server side. The Open XML file formats are a public standard.
Other alternatives, such as Spire.Office (edit word, export word to PDF, etc). spire.office.