2

I am trying to write some plugins to work with the Terminal Services Session Broker Plugin Interface. I am very fluent in C# but I have not done any C++ since the late 90's. For the plugin I am writing I plan on communicating with a database and I would prefer to use System.Data.SqlClient to talk to it as I know it's ins and outs fairly well. I have the Windows SDK which has provided my with the .idl file for the interface (tssbx.idl). The SDK also provides a C header file (tssbx.h) and a C source file (tssbx_i.c).

I have never written a COM server before, and I have been having a lot of trouble finding resources on learning how to read a IDL file and turn it in to C#. Everything I find says "Use TlbImport" but that requires things like the block library to be in the IDL which tssbx.idl does not (nor its dependents) implement.

What would be my best option:

  1. Find a tool for C# that is the equivalent to MIDL for parsing a .idl file in to a .cs file.
  2. Learn IDL (I have been having trouble finding good guides to learn it) and write the whole thing in C# by hand.
  3. Write a helper dll using the C files provided and have that call in to my C# dll for my .NET parts.
  4. Re-learn C++, use the provided .h and .c files, and use the CLR to make my .NET calls.
  5. Some other option I have not thought of.
Community
  • 1
  • 1
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431

2 Answers2

1

I am posting this as an answer because it is too long for a comment

From what I gather writing such plugins in .NET might raise problems later on - esp. in a scenario where more than one .NET-based plugin has to be loaded and the two (or more) plugins use different .NET versions (such problems has been expressly mentioned in the context of shell extenstions - I am just taking the reasons from that scenario as a basis for my suspicion...).

As to your option IDL itseld can't implement anything - it is an interface description language.

I would suggest using something similar to option #3 with some modification:

Implement the .NET part as a Windows Service and communicate between the C and the .NET via IPC - I would recommend using shared memory which is extremely fast and well supported with .NET4 .

Yahia
  • 69,653
  • 9
  • 115
  • 144
  • 1
    Indeed, there are risks involved in writing COM handlers in .NET. This is especially [problematic with shell extension handlers](http://blogs.msdn.com/b/junfeng/archive/2005/11/18/494572.aspx). Apparently, Microsoft has [sort of solved this problem](http://blogs.msdn.com/b/codefx/archive/2010/11/07/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-3-thumbnail-handler.aspx), but I would carefully study in what context my COM servers are used. – André Caron Feb 27 '12 at 17:15
  • They "solved the problem" by telling you not to do it, which kinda sucks :( – Michael Edenfield Feb 27 '12 at 17:30
1

The way to do what you're trying to do is to translate the IDL definitions into C# interfaces, then implement those interfaces as C# classes. You apply the appropriate attributes (mostly ComVisible, ClassInterface, and ProgId) to the classes you want to expose to COM, and use the regasm tool to register your assembly as a COM server.

Translating IDL into C# is actually not that complex; for the most part it maps pretty directly from IDL keywords to C# keywords and/or MarshalAs attributes. I have a series of blog posts on how to do COM interop w/out tlbimp, including one on how to read IDL. I don't know of any tools, specifically, that do a good job of this, but if its part of the Windows SDK you should always check pinvoke.net first in case someone else did it for you.

As far as your other options, 3 and 4 both amount to about the same thing. You cannot call managed code directly from unmanaged code unless it's done via COM Interop or a mixed-mode C++ library. In the first case, you'd still have to solve all of the problems of getting your C# assembly registered with COM for your C dll to call, so you may as well skip the middle-man. For the second, you are basically doing manually the same things that the runtime's interop code does for you, and using a language you're less familiar with to boot, which seems like a net loss to me.

Be aware, though, that loading .NET assemblies into an unmanaged context isn't always possible; for example, managed shell extensions are explicitly not support in Windows 2008. I don't know if the TSSBX interface will allow you to load managed assemblies as COM objects or not, so you'll have to be aware of that possibility. If you can't, then none of your options are going to work, and you'll have to avoid using the .NET Framework at all and use some other database access technology and write the entire project in unmanaged C++.

Michael Edenfield
  • 28,070
  • 4
  • 86
  • 117
  • I had a typo when I said "Write in IDL" when I meant "Write in C#", I fixed the typo while you where writing your answer. The part I was having trouble with was knowing what maps to what, it looks like your blog post will help a lot. – Scott Chamberlain Feb 27 '12 at 17:35
  • Cool, I took that part of my answer out so it won't seem so out of place :) – Michael Edenfield Feb 27 '12 at 17:37