C# 4 has some great features to make programming against COM components bearable fun and exciting. In particular:
- PIA linking allows you to embed just the relevant bits of the Primary Interop Assembly into your own assembly, so the PIA isn’t actually required at execution time
- Named arguments and optional parameters make life much simpler for APIs like Office which are full of methods with gazillions of parameters
- "ref" removal allows you to pass an argument by value even though the parameter is a by-reference parameter (COM only, folks – don’t worry!)
- Dynamic typing allows you to remove a load of casts by converting every parameter and return type of "object" into "dynamic" (if you’re using PIA linking)
I’m currently writing about these features for the book (don’t forget to buy it cheap on Friday) but I’m not really a COM person. I want to be able to see these compiler features at work against a really simple type. Unfortunately, these really are COM-specific features… so we’re going to have to persuade COM that the type really is a COM type.
I got slightly stuck on this first, but thanks to the power of Stack Overflow, I now have a reasonably complete demo "fake" COM type. It doesn’t do a lot, and in particular it doesn’t have any events, but it’s enough to show the compiler features:
using System;
using System.Runtime.InteropServices;
[assembly:Guid("86ca55e4-9d4b-462b-8ec8-b62e993aeb64")]
[assembly:ImportedFromTypeLib("fake.tlb")]
namespace FakeCom
{
[Guid("c3cb8098-0b8f-4a9a-9772-788d340d6ae0")]
[ComImport, CoClass(typeof(FakeImpl))]
public interface FakeComponent
{
object MakeMeDynamic(object arg);
void Foo([Optional] ref int x,
[Optional] ref string y);
}
[Guid("734e6105-a20f-4748-a7de-2c83d7e91b04")]
public class FakeImpl {}
}
We have an interface representing our COM type, and a class which the interface claims will implement it. Fortunately the compiler doesn’t actually check that, so we can get away with leaving it entirely unimplemented. It’s also worth noting that our optional parameters can be by-reference parameters (which you can’t normally do in C# 4) and we haven’t given them any default values (as those are ignored for COM anyway).
This is compiled just like any other assembly:
csc /target:library FakeCom.cs
Then we get to use it with a test program:
using FakeCom;
class Test
{
static void Main()
{
FakeComponent com = new FakeComponent();
int i = 0;
string j = null;
com.Foo(ref i, ref j);
com.Foo(10, "Wow!");
com.Foo(y: "Not me", x: 0);
com.Foo();
string value = com.MakeMeDynamic(10);
}
}
This is compiled either in the old "deploy the PIA as well" way (after adding a cast in the last line):
csc /r:FakeCom.dll Test.cs
… or by linking the PIA instead:
csc /l:FakeCom.dll Test.cs
(The difference is just using /l instead of /r.)
When the test code is compiled as a reference, it decompiles in Reflector to this (I’ve added whitespace for clarity):
private static void Main()
{
FakeComponent component = (FakeComponent)
new FakeImpl();
int x = 0;
string y = null;
component.Foo(ref x, ref y);
int num2 = 10;
string str3 = "Wow!";
component.Foo(ref num2, ref str3);
string str4 = "Not me";
int num3 = 0;
component.Foo(ref num3, ref str4);
int num4 = 0;
string str5 = null;
component.Foo(ref num4, ref str5);
string str2 = (string) component.MakeMeDynamic(10);
}
Note how the compiler has created local variables to pass by reference; any changes to the parameter are ignored when the method returns. (If you actually pass a variable by reference, the compiler won’t take that away, however.)
When the code is linked instead, the middle section is the same, but the construction and the line calling MakeMeDynamic are very different:
private static void Main()
{
FakeComponent component = (FakeComponent) Activator.CreateInstance(Type.GetTypeFromCLSID
(
new Guid(
"734E6105-A20F-4748-A7DE-2C83D7E91B04")));
if (<Main>o__SiteContainer6.<>p__Site7 == null)
{
<Main>o__SiteContainer6.<>p__Site7 = CallSite<Func<CallSite, object, string>>
.Create(new CSharpConvertBinder
(typeof(string),
CSharpConversionKind.ImplicitConversion, false));
}
string str2 = <Main>o__SiteContainer6.<>p__Site7.Target.Invoke
(<Main>o__SiteContainer6.<>p__Site7, component.MakeMeDynamic(10));
}
The interface is embedded in the generated assembly, but with a slightly different set of attributes:
[ComImport, CompilerGenerated]
[Guid("C3CB8098-0B8F-4A9A-9772-788D340D6AE0"), TypeIdentifier]
public interface FakeComponent
{
object MakeMeDynamic(object arg);
void Foo([Optional] ref int x, [Optional] ref string y);
}
The class isn’t present at all.
I should point out that doing this has no practical benefit in real code – but the ability to mess around with a pseudo-COM type rather than having to find a real one with the exact members I want will make it a lot easier to try a few corner cases for the book.
So, not a terribly productive evening in terms of getting actual writing done, but interesting nonetheless…
Jon Skeet's coding blog 