3

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

Adal
  • 41
  • 5
  • 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. – Security Hound Apr 03 '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 03 '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.** – Security Hound Apr 03 '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 03 '13 at 20:49
  • Which is the reason you should embed the library within your application. – Security Hound Apr 04 '13 at 11:13
  • I need to add the COM as a reference in my Visual Studio project in order to use it. It's the only entry point for a particular system (let's call it ABC), it acts as an API. The COM is registered in the system, it's not one of my assemblies. The moment I include the reference in VS, it creates an interop assembly which is now part of my application. – Adal Apr 04 '13 at 13:25
  • But the manufacturer of ABC is periodically adding new features to his product and some of them require changes in the COM component (I don't know if changes were done or not in the COM, there is not release note). I just need to know if there is a way to avoid rebuilding and redeploying on every new COM upgrade. I'm not even sure if I need to do it, but as far as I understand if there is a change in the COM interface I might need to update the interop DLL. My code itself is not modified. – Adal Apr 04 '13 at 13:26

3 Answers3

2

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.

Thorarin
  • 47,289
  • 11
  • 75
  • 111
  • 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 03 '13 at 20:32
  • if i remember correctly, tlb's are sometimes embedded directly inside the .dll what was delivered – Paul Farry Apr 03 '13 at 22:53
2

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 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 04 '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 '14 at 07:30
0

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" 
"C:\pathtocomdll\comcomponent.dll" 
/out:"Interop.mycomponent.dll" 
/asmversion:"1.1.0.0" /keyfile:"\\server\keyfiles\library.snk"  
/company:"my company"  /productversion:"1.1.0.0" 
/copyright:"2013" 
/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.

Paul Farry
  • 4,730
  • 2
  • 35
  • 61