Take the 2-minute tour ×

I have a C# .net 2.0 windows app that uses a COM component. Visual Studio 2005 automatically adds an interop assembly DLL when I add the reference to this COM library.

In case the COM component is upgraded frequently, what do I need to do to keep my app upgraded too? Do I need to upgrade the interop DLL? Do I need to rebuild and redeploy every time in order to keep up with the COM upgrade?

I don't understand 100% this interoperability issue, and I just need to minimize the work on every COM upgrade. I need to avoid rebuilding and redeploying every time. Is there any optimal way to achieve this?

I've been reading Advanced COM Interoperability (http://msdn.microsoft.com/en-us/library/bd9cdfyx.aspx) in MSDN and still don't have clear answer.

Thanks in advance

share|improve this question
You shouldn't have to recompile the program since the proper way to handle a situation like this is to supply the version of the file your application uses. –  Ramhound Apr 3 '13 at 20:21
Thanks Ramhound, but what do you mean exactly by "to supply the version of the file your application uses" ? –  Adal Apr 3 '13 at 20:29
In most cases when multiple versions of a library can exist on a system say DirectX the specific version used by the application is referenced instead of the version simply that exists on the system. If you don't do this then you will have issues reported that are caused by changes to the library. As for what .tlb files are thats well documented. –  Ramhound Apr 3 '13 at 20:39
The upgrade process removes the previous version of the COM and only leaves the new one. I will only have one version at any given time. I'm already doing my research on the TLB comparison option... and I already searched my entire system and can't find any tlb file for the COM in question. –  Adal Apr 3 '13 at 20:49
Which is the reason you should embed the library within your application. –  Ramhound Apr 4 '13 at 11:13
show 2 more comments

3 Answers

up vote 2 down vote accepted

and can't find any tlb file for the COM in question.

It is normally embedded in the COM server DLL. Something you can see with Visual Studio, File + Open + File and select the DLL. You'll see a TYPELIB node, resource 1 is the type library.

You can decompile the type library by running Oleview.exe from the Visual Studio Command Prompt. File + View Typelib and select the DLL. Copy/paste the content of the right pane into a text editor and save it. If there is any change in this IDL then you must rebuild the import library and your program. Not doing so can cause very difficult to diagnose runtime problems that include access violation exceptions and calling the completely wrong method.

This is hard to automate, clearly you'll prefer a better way for the vendor to let you know about breaking changes. The programmer that worked on this server should be well aware of the need for this.

share|improve this answer
Thanks Hans. I was able to find 4 different versions of the DLL, and then followed your procedure. Sometimes there are lots of changes. In this case I guess I will have to rebuild/redeploy the interop. Other times the only change is the line with the creation date. For example the line says (Created by ... at Mon Mar 20 08:35:10 2013) instead of (Created by ... at Fri Feb 12 12:20:17 2013). In this case I guess I don´t need to do anything. Now at least I have a way to identify important changes and avoid wasting my time. Great. –  Adal Apr 4 '13 at 16:33
@Hans Passant: I have the same problem as I am going to generate tlb by rebuilding .net obfuscated dll & If I rebuild that obfuscated dll security for code vanishes.Hence How can I generate tlb without rebuilding .net obfuscated dll? –  SkoolBoyAtWork Feb 24 at 7:30
add comment

You should not need to update the interop DLL, as long a the COM interface of the component does not change. Thus, it depends on what kind of changes are being made to the component.

Release notes would be the obvious source of information. Failing that, comparing .tlb files (if they are delivered with the component) might be an option.

Potentially, the component might support multiple interface versions as well, which would make it unnecessary to update your application immediately.

share|improve this answer
Thanks Thorarin. Unfortunately the COM provider does not include release notes in the package. It's an installer that includes many products, one of them the COM. So, I'm blind to major changes in COM interface. So, in order to play it safe, I guess I need to update too. What is exactly the .tlb file you mentioned? –  Adal Apr 3 '13 at 20:32
if i remember correctly, tlb's are sometimes embedded directly inside the .dll what was delivered –  Paul Farry Apr 3 '13 at 22:53
add comment

When I am doing COM interop with a component that I might be making lots of builds of, but the COM component isn't changing all that often, then i'll use TLBIMP to make a Interop that I just reference my interop that I can do versioning on (although to version the Interop may require .NET4).

Make all the following a batch file (single line) and use the appropriate tlbimp.

"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\tlbimp" 
/asmversion:"" /keyfile:"\\server\keyfiles\library.snk"  
/company:"my company"  /productversion:"" 
/product:"company product" /namespace:"company.namespace"

If the COM Component you are using is just upgrading their version but not changing their interface, then you shouldn't need to rebuild your Interop. If you are using .net4 you can also embed the interop in your project.

share|improve this answer
add comment

Your Answer


