COM Interop in C# 4.0

re: COM Interop in C# 4.0

samng — Wed, 22 Jul 2009 21:18:48 GMT

Wow, sorry I haven't been on here to answer anything in a while! Let me start from the top:

Commongenius:

> Ultimately, I don't like it, because I know that these "features" won't be confined to the usages for which they were intended, to the detriment of us all. But the world is imperfect, and we have to live in it.

I entirely agree. Someone else mentioned that it makes C# feel "dirty" - believe me, as the dev who implemented these things, I felt much dirtier. But it was a necessary evil I believe.

Xenan:

I don't think thats actually a problem, as much as it is an artifact of software engineering. You cant just move forward from version to version and simply assume you can wipe out any existing legacy concepts from previous versions. This is the nature of software design, and unfortunately is best solved through the language.

chrimart:

> If so, does that mean that Extension Properties would be back on the table?

Not currently. There were several things that took Extension Properties off the table, one of which was the indexed property problem. However, note that with this release, we're providing support for *consuming* indexed properties, not *authoring* them, so nothing would have changed from the extension properties front.

Richard:

Great catch, I've changed it from emit to omit. Thanks!

Pavel:

Thanks for your help answering questions that folks have! Let me just vouch for your answers and say that you are correct in your understanding of the features. The NoPIA feature (which I'll describe in upcoming posts) embeds only the types and members you use in your code into your compiled assembly, and removes the reference to the PIA. The CLR then does some magic to note that these types are equivalent, and treats them as such at runtime. More on that later :)

Thanks for your thoughts everyone, keep em coming!

re: COM Interop in C# 4.0

Xenan — Thu, 16 Jul 2009 16:30:20 GMT

The real problem is, of course, that Office is still a COM application whereas it could have been a .NET application from version 2003 on.

On one hand Microsoft seems to have a strong commitment to .NET but their flagship applications are still COM, which gives me mixed feelings.

re: COM Interop in C# 4.0

Pavel Minaev [MSFT] — Fri, 03 Jul 2009 21:31:23 GMT

> Dynamic may be "strictly an interop thing" by design, but in practice it can be used anywhere on any object, regardless of its origin. In my opinion this is a serious design flaw that will have long lasting negative consequences.

What are the alternatives? Unlike the rest of it, "dynamic" is not just for COM - it's also for interop with IronPython and other dynamic friends. And there's no good way to distinguish a "scripting" object from a non-scripting one - and, from multi-language .NET perspective - there really shouldn't be.

There's one more thing to consider. Let's consider IronPython interop again. Say you use "dynamic" to call a method on IPy object, and that returns you yet another object. Now you don't know what is returned - it may be another IPy object, but it also may be a C# (or other static language) object that IPy code obtained from elsewhere - and there's no reason why you should. But you have to have some common way to work with that object, and that means that "dynamic" has to work regardless of what the object is implemented in.

In my opinion, it's alright. A major compromise would be if C# allowed you to define truly dynamic "expando" objects (easily), but that is not the case.

re: COM Interop in C# 4.0

Pavel Minaev [MSFT] — Fri, 03 Jul 2009 21:27:00 GMT

> How can there be no PIA deployment? Who will do the interop?

If you've actually looked at what's in PIA assemblies, you'll see that there's no real code there - just interface declarations (and structs, where they apply). The framework itself does the interop.

What NoPIA means, effectively, is that you no longer need those PIA assemblies with interfaces. They get embedded directly into assemblies that use COM objects, and CLR ensures that such embedded types in different assemblies, even though technically distinct from CLR point of view, are compatible and can be substituted one for another when they actually correspond to the same COM interface/struct/etc.

Simply put, it's a form of structural typing specifically for COM interop artefacts.

re: COM Interop in C# 4.0

Tom Kirby-Green — Fri, 03 Jul 2009 19:03:20 GMT

What about interop'ing with 'pre VB generation' COM that returns S_OK or E_FAIL as logical booleans (i.e. soft rather than hard failure indicators). Then of course there's the S_FALSE problem.

re: COM Interop in C# 4.0

richard_deeming — Fri, 03 Jul 2009 17:26:59 GMT

It's a shame that this is required - it makes C# feel so "dirty" - but I can see why it's needed. It may have been possible to create .NET-friendly wrappers for the Office PI(T)A, but versioning would probably be a nightmare, and it wouldn't help with third-party COM libraries.

"the parameters are optional, indicating that you can emit them"

Shouldn't that be, "you can *omit* them"?

re: COM Interop in C# 4.0

Chris.Martinez.77 — Thu, 02 Jul 2009 00:19:14 GMT

Based on your statement, is it fair to say that C# 4.0 will have intrinsic support for indexed properties? If so, does that mean that Extension Properties would be back on the table?

As I understand it, the primary reason that Extension Properties are vetoed is because C# would have to support indexed properties and, as you've stated, the C# team thinks that is ill advised.

Extension Properties could be immensely useful and should have the same effective run-time capabilities as Extension Methods, since properties are ultimately a facade for get_xxx/set_xxx methods.

Working with the Silverlight BCL has proven to have great need for Extension Properties in order to duct tape types that are missing capabilities commonly found in the Windows-based BCL. For example, System.Threading.Thread.CurrentPrincipal was omitted.

re: COM Interop in C# 4.0

David A Nelson — Tue, 30 Jun 2009 17:51:42 GMT

@pminaev

Dynamic may be "strictly an interop thing" by design, but in practice it can be used anywhere on any object, regardless of its origin. In my opinion this is a serious design flaw that will have long lasting negative consequences.

However, it does appear that these changes designed for COM interop will only apply to COM objects, so the negative impact will be limited.

re: COM Interop in C# 4.0

Pavel Minaev [MSFT] — Mon, 29 Jun 2009 21:28:55 GMT

> Ultimately, I don't like it, because I know that these "features" won't be confined to the usages for which they were intended, to the detriment of us all.

The good thing about all these changes is that they _only apply to COM objects_! I.e., to interfaces and classes with ComImportAttribute. So it isn't a major compromise - you still can't pass values to ref-arguments on POCOs, or declared named indexed properties, etc. It's strictly an interop thing, much like dynamic.

re: COM Interop in C# 4.0

David A Nelson — Thu, 18 Jun 2009 01:40:04 GMT

I wish - I REALLY wish - that C# could stick to its design principles and not compromise for the sake of interoperating with languages and platforms that (IMHO) have made poor design choices.

However, I am forced to agree that COM isn't going away (as much as I wish it would), and many people still have to interoperate with it (as much as they probably wish they didn't). The only other thing I might consider is pushing these "features" into a secondary layer of the language that would have to be explicitly enabled (a la "Allow unsafe code"). But I can understand why that would be considered too extreme for this case (although I would be interested in knowing if something like that were even considered).

Ultimately, I don't like it, because I know that these "features" won't be confined to the usages for which they were intended, to the detriment of us all. But the world is imperfect, and we have to live in it.