locked
How does VB6.0 exe find a .Net dll it's referencing?? RRS feed

  • Question

  • I have found a mystery and I think the explanation may help me understand the COM interop better if someone would be so kind.

    Scenario:

    1. Developer reads bad stuff about GAC several years ago, so when we create C# libraries to do nifty stuff he decides they should be local and places them in...  \Program Files\MyCompany\Myapp\  where we have a VB6.0 executable that will call said .net assemblies.

    2. Because there are other libraries that end up using them, they are also placed with the libraries in \Common Files\MyCompanyShared\MyApp

    3. The installer actually installs and uses regasm on them in common files to generate TLBs, then they are copied to the  \Program Files\MyCompany\Myapp\ folder. They all should be the exact same TLB and Dll files.

    4. So far so good right :) - now people come behind and go why are these duplicated, lets remove them from \Program Files\MyCompany\Myapp\

    Thing is... everything still works, a run of Modules.exe shows all apps are correctly loading dlls from \Common Files\MyCompanyShared\MyApp and so it seems there was no reason to have them local (or duplicated).

    Everything I've read says they have to be in the GAC (they are not) or local (not anymore). So are they using PATH variable and searching until they find them like they would searching for a c++ dll? Because the Common Files\MyCompanyShared\MyApp is in the PATH variable. If so they would have to also be using the GUIDs since there are files named the same from another of our versions in a path that is prior to this one in PATH and it's not picking them up. It seems if this is true it is better than the GAC or local. Put your path in PATH and it will go through the list until it finds a binary with matching GUIDs? Someone please expound.
    Wednesday, July 30, 2008 9:12 PM

Answers

  • For each COM object the is a registry entry with the path to the assembly.  If you go to HKEY_CLASSES_ROOT\CLSID\{ClassIDObjectObject}\InProcServer32 in reg edit you should see the path. 
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    Thursday, July 31, 2008 5:43 AM

All replies

  • For each COM object the is a registry entry with the path to the assembly.  If you go to HKEY_CLASSES_ROOT\CLSID\{ClassIDObjectObject}\InProcServer32 in reg edit you should see the path. 
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    • Marked as answer by ShawnGarrison Thursday, July 31, 2008 12:37 PM
    Thursday, July 31, 2008 5:43 AM
  • So if that's how it's found, are there any negatives to using this method? Everything I read keeps saying you either put it in the GAC or put it local. Is this only working because I'm running a VB executable that's calling a COM registered component? What if I created a .Net executable in the program files folder that referenced these Dlls? Would it have trouble finding them since they weren't in the GAC or local?
    Thursday, July 31, 2008 12:41 PM