Developing with COM Components

[RookPSU]

I have a few Com.dll's that I use in a multiple of my applications. These are in house .dll's which are rebuilt a few times a month when we discover bugs or decide to add minor functionality.

 

Since I've started building in .NET I've been forced to create (or at least I assumed this was the ideal way) primary interops for these .dll's and stick them in my GAC. Therefore all the applications (VB6 or VB.NET) that use the .dll can pull from the same file. The only problem is, it seems everytime I build my COM.DLL I have to create a new primary interop and install it in the GAC. My question is, if I choose not to auto-increment the dll version on build (assuming i 'm not changing the interface) can I continue to work without recreating an new interop?

 

I have yet to find the reccommended way of building with COM components in the manner that I do. From what i've been able to ascertain it seems that the GAC is something that should only be utilized on the client machine - UNLESS you're working with interops.

 

Any help would be appreciated.

 

-Ryan

[Mike_R]

My question is' date=' if I choose not to auto-increment the dll version on build (assuming i 'm not changing the interface) can I continue to work without recreating an new interop?[/quote'] I'm going to guess that the answer to this is "no". That is, you would have to keep creating a new Primary Interop every time.

 

I've not played with what you are taking about, but here is my thinking...

 

Each time you change your COM.DLL, even if you do not "break binary", and therefore maintain the same GUID, you are still potentially adding functionality. .Net will not recognize the new functionality unless a new PIA is made for it. It is possible that an older-generated PIA is still functional (and therefore a candidate for the GAC), but you would have to test this I think. In theory, if you do not break binary, then all the VTable's should be the same and so the old PIA could work, but there may be more to this on the .Net side of things that don't allow an old PIA to actually work with an updated COM DLL.

 

As for putting an Interop PIA in the GAC, I don't know how important that is. When you use, say, MS Office 2002 or MS Office 2003, it's best if one references the PIA's found in the GAC and not make (or distribute) a locally-created PIA. But as for functionalty, I don't think it really matters; the point of doing this is that if MSFT offers patches or updates to the PIA, your local version would not see the fix. Beyond that, I don't really see the "big deal", but I could be missing something here, I'm not sure...

 

For your own COM DLLs, esp. if they are changing, I don't really see the benefit of going through the hassle of putting it in the GAC. I would just distribute any updated DLL along with the updated PIA.

 

-- Mike