Lesson 1

Welcome to COM Fundamentals II. In this course, we will expand on the concepts covered in COM Fundamentals I.
Specifically, we will study COM's (Common Object Model's)

1. reuse mechanisms,
2. containment/delegation and
3. aggregation.

Our course projects will involve creating two new COM objects that reuse the PhBookObj object developed in the COM Fundamentals I course.
In the first project, we will create an in-process COM object called Memo, implemented in COM server InfoMgr, that reuses PhBookObj via containment/delegation.
In the second project, we will create COM object MemoAgg, in server InfoMgrAgg, that reuses PhBookObj via aggregation and also implements interface IMemo. Additionally, we will develop a COM client called InfoMgrCli that uses both our new COM objects: InfoMgr and InfoMgrAgg.
By the end of this course, you will be able to:

1. Understand source code and binary-level reusability
2. Understand COM's reusability mechanisms
3. Understand containment/delegation
4. Develop a COM object that reuses another COM object via containment/delegation
5. Understand aggregation concepts
6. Develop a COM object to support aggregation
7. Develop a COM object that aggregates another COM object
8. Develop a COM client that uses composite COM objects built from containment/delegation and aggregation

Microsoft's Component Object Model (COM) is a system for reusing software artifacts at the post-compilation level or binary level . Using COM, one or more computational functionalities of a component can be made available through a system call and through constructs called interfaces. A client of a component, for example a program that needs the functionalities of the component, is served through a protocol called interface negotiation. Several components may be combined into one component using the aggregation method to put all or part of the functionalities of the constituent components into the new component.

Component Object Model provides a facility to reuse software artifacts. Several programs running on a system (a personal computer running a Windows 10 operating system) can share loaded COM software (called a server) to get a number of computational processes. The source code of the program may be from different programming languages. There are several ways to reuse software artifacts including

1. reusing source code,
2. reusing flowcharts or diagrammatic expression, and
3. reusing concepts.

The stated cases of artifact reuse can be categorized as the pre-compilation ones. Reusing a .dll or a .exe file is a case of reuse at the binary level for software artifacts. A change in a non-COM .dll or .exe library usually requires a significant amount of work for adjusting it to a specific a client. COM, a standard of reusing software artifacts at the binary level, helps reduce the amount of such adjustments at a client side.

In the first release of the .NET framework, COM (Component Object Model) played a crucial role as a bridge between older technologies and the new .NET environment. Microsoft had a massive investment in COM-based technologies before .NET was introduced, and .NET needed to interoperate with existing systems that used COM components.
Here’s how COM was utilized in the .NET framework:

1. Interoperability with Legacy Systems: .NET provided COM Interop services, which allowed developers to use existing COM components within .NET applications. This was essential because many enterprise systems and applications still relied heavily on COM components at the time. The interop feature allowed a smooth transition for companies moving from COM-based applications to .NET without needing to rewrite everything immediately.
2. COM Callable Wrapper (CCW): The .NET framework introduced a feature called the :COM Callable Wrapper (CCW):, which allowed .NET objects to be exposed as COM components. This way, legacy COM applications could call .NET objects as if they were COM components. This capability helped developers gradually migrate their systems from COM to .NET.
3. Runtime Callable Wrapper (RCW): Similarly, the :Runtime Callable Wrapper (RCW): enabled .NET applications to call methods and properties of existing COM components. The RCW would handle the marshaling of data types and function calls between the managed (.NET) and unmanaged (COM) environments, ensuring seamless interaction between the two.
4. Platform Invocation Services (P/Invoke): For lower-level interoperation, .NET used :P/Invoke:, which allowed .NET code to call functions in unmanaged libraries, including those exposed by COM. While not exclusively for COM, this was another important tool for integrating with legacy systems.
5. Transitioning Strategy: Microsoft saw .NET as the future, but they understood the need for organizations to continue supporting and extending existing COM-based systems. By providing strong interoperability features between .NET and COM, developers could extend and enhance their COM applications with .NET technologies, making the transition smoother.

Overall, COM in .NET 1.0 served as a bridge technology, allowing organizations to maintain investments in existing systems while migrating to the .NET ecosystem. The ability to leverage both COM and .NET components in the same application helped ease the adoption of the .NET platform.