 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Interop / March 2008To Reference Interop.XXX.dll or XXX.dll
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? (I apologize for having posted this in microsfot.public.dotnnet.general before finding this more appropriate newsgroup)  SignatureJD Developer If you reference the COM component, Visual studio will automagically creates the interop assembly. It will do so by either invoking tlbimp or aximp for you. The real .NET reference is therefore interop.XXX. (Of course this doesn't mean you shouldn't ship the com dll with your app) You can manually create the interop assembly by invoking tlbimp. This tool will allow you to give the assembly as strong name, specify the namespace and the references. It also lets you create a primary interop assembly. >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 [quoted text clipped - 15 lines] > (I apologize for having posted this in microsfot.public.dotnnet.general > before finding this more appropriate newsgroup) My bottom lien question is this: Is it preferable to reference the Interop.XXX.dll you make with tlbimp, or to reference the COM DLL and let it handle the Interop.XXX.dll? SignatureJD Developer > If you reference the COM component, Visual studio will automagically creates > the interop assembly. It will do so by either invoking tlbimp or aximp for [quoted text clipped - 25 lines] > > (I apologize for having posted this in microsfot.public.dotnnet.general > > before finding this more appropriate newsgroup) > My bottom lien question is this: Is it preferable to reference the > Interop.XXX.dll you make with tlbimp, or to reference the COM DLL and let it > handle the Interop.XXX.dll? There is probably no general answer to this. If the COM DLL is your own product, it could be worthwile to manually deliver an official *primary* interop assembly. Otherwise, why not let Visual Studio know that you are actually depending on a COM DLL, it will then rebuild the Interop as required and show you a broken reference if the COM dll is not installed properly. JD, There actually is a good answer to this. But its not for performance or anything to that degree. Let's say you have a build machine that doesn't have the COM DLL available for interop creation. You can manually create the interop assembly, place it in your source tree as an external binary dependency, then your build machine would be happy. It wouldn't be able to run the project (or at least not the parts that use the COM object) but it will build it without issue. I'm sure there are other similar scenarios. Adam > My bottom lien question is this: Is it preferable to reference the > Interop.XXX.dll you make with tlbimp, or to reference the COM DLL and let it [quoted text clipped - 29 lines] > > > (I apologize for having posted this in microsfot.public.dotnnet.general > > > before finding this more appropriate newsgroup)
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.