To Reference Interop.XXX.dll or XXX.dll

[JD]

I am trying to find something definitive on whether, for a COM DLL (we'll
call it XXX.dll) that I want to use in C#, I should reference the COM DLL and
let the IDE create the Interop.XXX.dll file, or create it the Interop.XXX.dll
myself and reference ONLY the Interop.XXX.dll in the project and NOT the
XXX.dll.

All I have read so far (the last 7 years working with .NET), and all I can
find now says to do what I have been doing, just referencing XXX.dll and let
the IDE build the Interop.XXX.dll. Now I am being asked by some folks that
are new to C# and .NET why not just reference the Interop.XXX.dll.

Any ideas?

 

[Norman Yuan]

If the COM DLL is created by a third party, you should alway look for its
PIA (primary interop assembly) provided by the vendor. Such as MS Office. If
there is no PIA available, then you can only create the Interop.XXX.dll by
yourself (actually, by VS). When you set refernce in VS to XXXX.dll, what VS
does is generate the Interop.xxx.dll first, and then set reference to the
generated interop.xxx.dll. So, to anwer your question, the VS can only set
reference to interop.xxx.dll, whether is is provided by the COM DLL author,
or generated by VS; if there is PIA available to the COM component, use
that, instead of generating it with VS.

 

[JD]

I should have added that these are VB6 DLLs that are ours and since they are
not signed, have no PIAs.

It seems to me, and I am open to correction, that the most
maintenance-friendly approach is to reference my DLL, and let it update the
Interop if and when the COM DLL changes its interface (which in VB6 can
change without the GUIDs apprearing to change).
--
JD
Developer

If the COM DLL is created by a third party, you should alway look for its
PIA (primary interop assembly) provided by the vendor. Such as MS Office. If
there is no PIA available, then you can only create the Interop.XXX.dll by
yourself (actually, by VS). When you set refernce in VS to XXXX.dll, what VS
does is generate the Interop.xxx.dll first, and then set reference to the
generated interop.xxx.dll. So, to anwer your question, the VS can only set
reference to interop.xxx.dll, whether is is provided by the COM DLL author,
or generated by VS; if there is PIA available to the COM component, use
that, instead of generating it with VS.

 

[Norman Yuan]

If the COM DLL is changed, of course you need to give up previously
generated Interop.xxx.dll and regenerate one by setting refernece to the COM
DLL in VS. If you set your VB6 project to keep binary compatible, then, as
long as the binary compatibility is not broken by your fix on the COM DLL,
you do not need to regenerate the Interop.xxx.dll.

I should have added that these are VB6 DLLs that are ours and since they
are
not signed, have no PIAs.

It seems to me, and I am open to correction, that the most
maintenance-friendly approach is to reference my DLL, and let it update
the
Interop if and when the COM DLL changes its interface (which in VB6 can
change without the GUIDs apprearing to change).

 

[JD]

Then my last question in this is: Is there some advantage to referencing the
Interop.XXX.dll over just referencing the XXX.dll? I would think for
maintainability, the reference would be to XXX.dll, and if a new
Interop.XXX.dll is made, the include it in the distribution files for the
app.