locked
Registering .Net for COM Interop RRS feed

  • Question

  • Sorry for my inexperience, but I am not very familiar with COM. I have C# libraries that needs to be consumed by some legacy COM apps. With the current system I use Regasm /tlb during the build to output TLB files that are used. This has worked fine for as long as I have been here. Unfortunately, our system requires multiple versions of the software to run concurrently and we are releasing another major release with new binary comp, guids, binaries etc... The developers managing the COM are changing their binaries names which they say is required for COM to run two binaries concurrently as they are registered by name. This is requiring weeks of updating references and build procedures.

    Main question is, since I register my .Net assemblies for COM interop using Regasm /tlb do I need to rename my assemblies? Is renaming the TLB enough?

    Secondary question, is this really necessary for the legacy COM stuff? Is there no better solution than making mydll.dll become mydll2.dll??

    Any help is greatly appreciated!!!

    Shanw
    Tuesday, July 22, 2008 1:22 PM

Answers

  • You're in luck, you're wrong.  COM finds the DLL to load from the GUID of the class.  The GUID in AssemblyInfo is irrelevant, it is the [Guid] attribute that was used on the interface declaration in your managed code.  I know I can't convince you of this, good luck with it.
    Hans Passant.
    • Marked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    • Unmarked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    • Marked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    Tuesday, July 22, 2008 11:44 PM

All replies

  • No, that's completely the wrong approach.  Changing the COM interfaces requires changing the GUIDs for the interfaces.  Changing the DLL names is pointless, they are stored in the GAC.  The GAC can store multiple DLLs with the same name and a different version.  COM doesn't care at all what the DLL name is, it only goes by the GUIDs.
    Hans Passant.
    Tuesday, July 22, 2008 7:45 PM
  • Are saying this is completely the wrong approach for COM too or just .Net?

    Tuesday, July 22, 2008 7:52 PM
  • For COM too.
    Hans Passant.
    Tuesday, July 22, 2008 7:54 PM
  • If for COM something is being misunderstood about how COM works I think. I was doing some testing on my own with the COM components to see what was going on and this is the scenario...

    Install MyApp XP which has MyDLL.dll version 1.3 into folder \MyAppXP 
    -all builds of this release are set binary compatible in VB6

    Install MyApp V which has MyDLL.dll version 2.6 into folder \MyAppV
    -binary compatibility was turned off until a full build was created then turned back on to have dlls with new GUIDs for the new release

    This didn't work as the old apps from version MyAppXP now starting using the Dlls in \MyAppV and caused errors. I didn't think there would be problem in my C# assemblies, but the first build was installed along side the older apps and it started using my new binaries causing errors. What am I missing?
    Tuesday, July 22, 2008 7:57 PM
  • I've never heard of "binary compatibility" as a feature of .NET projects.  How do you turn that on and off?
    Hans Passant.
    Tuesday, July 22, 2008 9:41 PM
  • No the binary compatible setting is in vb6. I was talking about COM in general, not using .Net.

    For .Net we had GUIDs set in the assemblyinfo. When we moved to the new release we changed the GUIDs for the new version of the Dll.
    Tuesday, July 22, 2008 9:47 PM
  • I've been scouring the web for information on COM and it looks like their right about their vb stuff. The new versions have to have a whole new name to avoid conflict.

    I am assuming my .Net problem is coming from generating the TLB. Having...

    mydll.tlb in folder \myappxp

    mydll.tlb in folder \myappv

    ...is the same as having two vb dlls of the same name conflicting. If this is the case then to have the vb apps correctly consume the right tlb I'd have to rename the binaries and generate new tlbs.

    COM seems quite horrible (at least with VB) if you can't have two libraries registered that happen to have the same name even though they have different guids and locations. From what I've read this mainly just applies to VB and you can use versioning with COM in C++. I would love to be wrong here.
    Tuesday, July 22, 2008 10:21 PM
  • You're in luck, you're wrong.  COM finds the DLL to load from the GUID of the class.  The GUID in AssemblyInfo is irrelevant, it is the [Guid] attribute that was used on the interface declaration in your managed code.  I know I can't convince you of this, good luck with it.
    Hans Passant.
    • Marked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    • Unmarked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    • Marked as answer by ShawnGarrison Friday, July 25, 2008 3:21 PM
    Tuesday, July 22, 2008 11:44 PM
  • It's not that you can't convince me of this, it's just that so far I haven't had much luck getting this to work.

    Also, I was confusing what you were saying about COM to being synonymous with VB6 use of COM which research is telling me may not be the case. All the Microsoft documentation I've found says that you can't have two VB6 Dlls with the same name or when you register the second one everything that referenced the first will now reference the second. While I've seen a few methods to control this none are all encompassing enough to cover all the environments our clients use. I have no idea why this would be specific to VB6 and have ordered several COM books to try to get up to speed. For now I am going to try your suggestion and see if it works for my .Net assemblies.

    Thank you
    Wednesday, July 23, 2008 12:42 PM
  • Have you considered using a manifest file to isolate the COM components?

    http://msdn.microsoft.com/en-us/magazine/cc188708.aspx

    Apologies if I'm misunderstanding what you're trying to achieve.

    Wednesday, July 23, 2008 10:51 PM
  • You have the right idea, but manifests and registration free COM in general only work for Windows XP and above and we have lots of users on windows 2000 workstations. I think nobugz has the right idea for my .Net assemblies it's just taking awhile to get everything setup to test it.

    For the VB source, everything I read says it's easier and safer to just rename the binaries.
    Thursday, July 24, 2008 12:58 PM
  • nobugz said:

    You're in luck, you're wrong.  COM finds the DLL to load from the GUID of the class.  The GUID in AssemblyInfo is irrelevant, it is the [Guid] attribute that was used on the interface declaration in your managed code.  I know I can't convince you of this, good luck with it.


    Hans Passant.

    Hi I changed all the GUIDs on the interface declarations and rebuilt. When I install it along side our older version and run old versions of the VB apps, it's still loading the new(wrong) binaries that were just installed.  What else do I have to do to make sure that my old versions load the old binaries?

    Thursday, July 24, 2008 3:48 PM
  • Did you re-register the old DLL?  Look with Regedit32.exe at the registry keys in HKLM\Software\Classes\CLSID and verify that the old GUID is still there and is pointing to the old DLL.
    Hans Passant.
    Thursday, July 24, 2008 5:13 PM
  • Thanks for everyone's input. I found the answer. Basically NoBugz was correct I just needed to take it a step further. After trying stuff one at a time and testing I figured out that once I found and changed ALL GUIDs for ALL public classes, interfaces, AND enums then everything registered correctly and the versions were able to run concurrently.

    thank you!
    Friday, July 25, 2008 3:21 PM