Examples of COM Automation in Silverlight 4

Introduction

In the previous article we talked about COM automation support introduced in Silverlight 4 and we said that COM automation is available only for Silverlight OOB (Out-of-Browser) applications that have Elevated Trust, and that's one of the security restrictions imposed by Silverlight.

Today, we're going to talk about COM automation in more details and give few Silverlight examples that make use of this great feature.

Concepts

Finding COM Components

 

COM components expose their interfaces and classes via Windows Registry. COM classes exposed to public available in this machine are registered in the Registry at HKCR\CLSID (which is a repository for all COM classes registered in this machine.) Because the machine may have thousands of COM components installed, every COM class is identified with a GUID (Globally Unique Identifier.) This GUID is very long and difficult to remember (it's something like {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}) so COM classes are using another way to identify themselves; that is the ProgID (Programmatic ID.)

ProgID for a COM class is a simple and clear string that identifies that class and represents it. For example, Microsoft Word exposes its functionalities through a COM class that you can reach it using the ProgID Word.Application. So, instead of the GUID of a class, you simply refer to it using its simple and easy-to-remember ProgID.

Then, how to find the right COM component? Or how to know if a COM component exposes a certain functionality that I need? Google it, that's the only way! If you are looking for a COM component that does something you need just google it. And always have the COM component in your right hand, and have its documentation in the other. And don't miss a chance to ask MSDN for help.

Accessing the COM Component

 

Now you have the COM component and know what to do with it. The next step is to create a new instance from the COM class using its ProgID. This is can be done using the AutomationFactory class found in the namespace System.Runtime.InteropServices.Automation (exist in System.Windows.dll.) This class exposes a few functions and only one property. The only property is IsAvailable that returns whether or not COM is supported by the operating system (COM is supported only in Windows.) Of the few functions AutomationFactory supports, we care about only CreateObject() that takes the ProgID as an input and returns the created object.

COM and Late Binding

 

When you assign an object to a variable that assignment can be made as early-binding or late-binding.

Early-binding is that what you make every day and all the time. By default, object assignment is made as early-binding, means that you create a variable of specific type and bind that object to that variable. Then, the compiler always knows the type of object assigned and the members (methods, properties, etc.) it supports and that allows him to do some checks, optimizations, and perform some memory allocations before application start.

In addition, early-bound variables can be thought as strongly-typed objects, means that you can check for their exposed members, use some IDE features like Intellisense and Object Explorer, and also receive compiler errors when you try to make calls to members that don't exist (for instance.)

Late-binding on the other hand is made at runtime, means that the compiler doesn't have enough information about the type at compile time. That means that no type checks, no method lookups or Intellisense, no verifications, no optimizations, and also no compilation errors from the late-bound object.

Is there any benefit from late-binding? Does it have anything to do with COM? Actually, it's not as ugly as you think, it has lots of benefits and it also the core of COM automation in Silverlight (and .NET 4.0 too.)

Read more: C# Corner

Posted via email from Jasper-net