6

I've never seen this question answered definitively:

If you are maintaining a COM DLL that can be used by a .NET program, is it best to:

  1. Import the COM DLL into each project, which generates an Interop assembly for each project? or

  2. Generate the Primary Interop Assembly with TLBIMP every time the COM DLL is compiled? or

  3. Write the Primary Interop Assembly in C# and compile that every time the COM DLL is compiled?

I would like to do either number 2 or number 3. Number 2 sounds compelling, but I cannot see how you set the AssemblyTitleAttribute (and other such attributes); I would assume you use custom attributes in the IDL which TLBIMP would pick up.

Null Pointers etc.
  • 161
  • 5

2 Answers2

1

I really hate giving you an "it depends" answer... but it depends!

Generally relying on the generated Interop file is fine if your project setup is quite trivial. When you have a lot of projects and/or when you use strong naming, then things can get a little trickier. In our case, we basically have strong naming for everything, and this includes the Interop files. We compile our projects via a script on our integration server, and generate all of our Interop files on the fly when we need them, but before we compile our project source. In this way, we don't have to think about all of those edge cases where accessing assemblies might not work. In this case it looks like we're implementing your second option, and usually don't bother with the first option unless it's something very trivial and we don't need to rely on strong naming or on a prior build - for whatever reason.

As for the 3rd option, I can't imagine how you'd ever need to create your own Interop files given you've got 2 other options at your disposal which do the task much more easily for you.

S.Robins
  • 11,385
  • 2
  • 36
  • 52
0

In one of my projects, we implemented option 2. The generation involved creating the assembly, disassembling it using ildasm, reassembling it back using ilasm and finally signing it. The reason for the roundtrip was that we wanted to embed version information into the PIA.

AFAIK, option 1 won't allow exchanging COM objects between different applications.

Option 3 surely gives you the full power of designing the interop "the way it should be", not the way it is spat out by tlbimp. Writing simple forwarders is not that hard, but tlbimp does this job quite well already. If you really want it "the way it should be", the interop may very well become a complex project in its own right.

krlmlr
  • 783
  • 5
  • 13
  • As I understand it, Option 3 allows you to embed information (such as your version information). It would seem to me that disassembling and then reassembling would be hard to do, whereas keeping the source code to the PIA in C# and modifying the source code in parallel would be easier. – Null Pointers etc. Feb 03 '12 at 22:39
  • Well, it depends how much you want to change. In our case the disassembly/assembly way was fairly simple, because we didn't need to edit the code, only add a resource. But I get your point. – krlmlr Feb 03 '12 at 22:46