. NET components and COM components & managed and unmanaged code

COM components and. NET components:

COM components are unmanaged objects and may not be required. NET Framework and run it directly. NET Framework components are managed objects and must have. NET Framework for the support to run.

COM components have separate type library files, and. NET components are self-referencing by using an assembly manifest

COM components communicate on an interface, while. NET components communicate directly without querying through an intermediate interface
The COM component must register the DUID entry in the registry. NET components without the need for any manual registration
COM components can and only register one version at a time. NET components can coexist

Managed and unmanaged code:

1 Simply put, the code is compiled into MSIL and runs under the framework of. NET, and the underlying interaction with the operating system is given to the framework. The so-called unmanaged code is out of control of the framework, dealing directly with the underlying API, managing its own memory and security mechanisms, and much more. And the managed code doesn't matter, it's all done by the framework.

2 "program" is generally in the operation of the operating system directly or indirectly
A "managed program" is a program that requires access to the common language runtime (CLS) to access the operating system
Unmanaged programs do not have direct access to the operating system's programs by accessing the common language runtime (CLS)

Note:

Question: What is a COM component? The
Answer:com component is made up of executable code that is published in the form of a WIN32 dynamic-link library (DLL) or executable file (EXE). COM components are COM components that are written in accordance with COM specifications are small binary executable COM components that can provide services to applications, operating systems, and other components. COM components that can be customized to the application, the OS, and other component may be connected together with other components at runtime to form an application COM components that can be dynamically inserted or unloaded by an application COM component must be a dynamically linked COM component that must be hidden (encapsulated) in its internal implementation details the COM component must implement a language-hidden COM component that must be published in binary form for COM components to be upgraded without prejudice to existing users COM components can be transparently redistributed on the network where COM components declare their presence in a standard way

Question: When do I need to build a new version of COM components?
 answer: When a new ID is specified for an existing interface, at least one of the following conditions should be true. When the number of functions in the interface has changed. The order of the functions in the interface has changed. An argument for a function in an interface changes the order in which a function in an interface changes the parameter of a function in an interface changing the type of the function in the interface changes the return value of a function in the interface changing the meaning of the function in the interface changes the meanings of the functions in the interface change simply say, COM is a way to share binary code across applications and languages. Unlike C + +, it advocates reuse of source code. ATL is a good example. Source-level reuse is good, but only for C + +. It also brings the possibility of name collisions, not to mention the constant duplication of code reuse that results in engineering bloat and bloat. Windows uses DLLs to share code at the binary level. This is also the key to the operation of Windows programs-reuse Kernel32.dll,user32.dll and so on. But DLLs is written for the C interface, and they can only be used by C or the language that understands the C call specification. The programming language is responsible for implementing shared code, not by DLLs itself. In this case, the use of DLLs is limited. MFC introduces another kind of MFC extended DLLs binary sharing mechanism. However, its use is still restricted-it can only be used in MFC programs. COM solves these problems by defining a binary standard that COM explicitly states that binary modules (DLLs and exes) must be compiled to match the specified structure. This standard also specifies how COM objects are organized in memory. COM-defined binary standards must also be independent of any programming language, such as named adornments in C + +. Once these conditions are met, it is easy to access these modules from any programming language. The binary code generated by the compiler is compatible with the standard. This makes it easier for later people to use the binary code. In memory, this standard form of COM objects is occasionally used in C + + virtual functions, so this is why many COM code uses C + +. But remember, the language used to write the module is irrelevant, because the resulting binary code is available for all languages. In addition, COM is not unique to Win32. Theoretically, it can be ported to UNIX or other operating systems. But I never seem to have heard of COM outside of Windows.

. NET components and COM components & managed and unmanaged code