Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

for the benefit of being lazy

Sign in to follow this  


Spent more time playing with a throw away side project today than I intended to. I had forgotten how much C#'s COM interop annoys me.

Back on the actual planned project arena, I spent more time than I intended trying to come up with a mark up scheme for the personal wiki project. At this point I think I'm just going to say "the heck with it" and implement a really basic markup, just enough to get to work on the back end stuff. Probably just []-style links with no pretty names or escaping right now. Once that's in place I'll start seeing about handling the navigation events from the embedded browser.

As I've mentioned, right now I have IE embedded as a display control. It's a fairly simple process to pipe raw HTML into it. I've been thinking about trying Gecko out instead. If I can get all that to work, I might have all the building blocks I need for one of the subsystems I wanted to put into Seventh Star. That would be neat.

Yay, this project actually ties back into game development some how.
Sign in to follow this  


Recommended Comments

Where to start... well my first complaint would be that even when you have an existing type library, the automatic import (w/ .NET 2003 anyways) often leaves something to be desired. For example, my current project I'm working on imports ShDocVw.dll. So there's a nice happy Interop.ShDocVw.dll file sitting in my project directory. However, the types seem to be imperfectly loaded into the IDE. For example, AxSHDocVw.DWebBrowserEvents2_BeforeNavigate2Event shows no members in the Object Browser; however, that information does exist in the interop assembly, since ildasm shows all the members happily, and using those members in source code compiles properly.

But when you don't have a type library, that's where the real fun begins. COM interfaces are represented by C# interfaces, which is fair enough. However, C# interfaces can't inherit from one another, which means that instead if you need to write an interface class with inheritance, you need to manually duplicate the function signatures in the child interfaces, and in implementation classes, you have to remember in implement both the child and the parent interfaces. Otherwise you might have strangeness like IPersistStreams that aren't IPersists. This is a level of hassle that implementing a COM interface in C++ doesn't have. And I don't think I should have to explain just how wrong *that* is.

Then you have the joy of decoding function signatures from IDL files or C/C++ headers into C# declarations. And there's decomposing structure types as well. When all is said and done, with the attributes you need to plaster on everything to make sure that everything is compatible, you've probably written more code than the equivalent C++ implementation, and you're less sure that everything works properly (should I have declared this as a [MarshalAs(UnmanagedType.Interface)] out Object or maybe a [MarshalAs(UnmanagedType.IUnknown)] ref Object?). See the above just wrong comment.

I could go on, but there's not much point. Let's just say I'm looking forward to the next version of C# to see if they streamlined things any better.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!