Chapter 34. Working with the Component Object Model (COM)
This chapter covers
- Discovering what COM is and isn’t
- Working with COM objects
Get ready for a blast from the past! Before Microsoft invented the .NET Framework, folks relied on an earlier technology called the Component Object Model (COM). COM is basically a set of rules that enable developers to write software components that can easily interoperate. COM is still in wide use today, although it’s considered an older cousin to the .NET Framework. Many technologies you rely on, and use with PowerShell, are still based on COM. Examples include Active Directory Services Interfaces (ADSI) for working with Active Directory, WMI, and the object models that enable you to script against Internet Explorer or the Office products such as Word and Excel. COM is here and unlikely to go away in the foreseeable future. Unlike .NET, whose components can’t run without the .NET Framework itself installed, COM doesn’t have any specific prerequisites—many pieces of COM software can run on any Windows computer.
Because so much functionality was written in COM, the .NET Framework originally shipped with—and still contains—the ability to load and use those pieces of software that comply with the COM specification. This is done through a .NET Framework layer called the interop layer. PowerShell, through interop, is able to take advantage of many pieces of COM-based software.