title: COM registration fails: "Automation error: the system cannot find the file specified", when installing dll into other folder than the tlb file
body: <p>We have a COM component (let's call it MyLib) developed in VB.NET, for our Access application (let's call it MyApp) to use. In order to do that, we need to do COM registration using the generated MyLib.dll and MyLib.tlb files. When I am installing both files into our MyApp's folder, everything is working fine, the COM function is invoked correctly. However, I am having an error mentioned in the title when I am installing the dll into a common folder - the reason I am doing it is because we want to allow different versions of MyApp to be installed on the same machine. So if the COM component doesn't change, we of course want to share it among these different versions and let Windows do the reference count. </p>
  
  <p>I am not sure where I should put the MyLib.tlb file, either in MyApp's installation folder, or the same common folder as MyLib.dll. But anyway, I tried both locations, and they all gave the same error. I tried to compare the registry files between the case when I put MyLib.* into MyApp's folder, and the case when I put MyLib.dll into common folder. I can't see any difference except of course the CodeBase of the Class I am trying to register under HKCR\Wow6432nodes\CLSID{MYCLSID}\InprocServer32. Another thing I don't understand is there is no sub-key named TypeLib under HKCR\Wow6432nodes\CLSID{MYCLSID} in both cases, which in my understanding is the way to link the TypeLib to the dll (but why is is still working when I put tlb and dll into the same folder?) since in MyApp it only knows that there is a reference we add by reference of MyLib.tlb.</p>
  
  <p>I don't understand exactly how COM reference works for Access application, so if I am wrong please correct me. Can anybody tell me what I did wrong? What is the correct way to register a shared COM dll (whether put both dll and tlb into shared folder or not)? Thanks!</p>
  
  <p>UPDATE:</p>
  
  <p>Regarding the COM registration, I am using WIX to create a Windows installer and heat.exe to harvest the information from dll and tlb files. The generated file includes the information of Class, ProgID, TypeLib, and Registry tags. As I mentioned, the only difference between my two cases, from WIX configuration's point of view, is the location where I put MyLib.dll file (I assume putting MyLib.tlb file in MyApp installation folder is the correct way, again, please correct my if I am wrong), and when I put both dll and tlb files into application's installation folder, it does work. Here is some registry structure after the registration </p>
  
  <p>Firstly I have HKCR\CLSID\{MYCLSIDs}, each of them represents one of my COM class. in the sub-key named "InprocServer32", I have Assembly, Class, CodeBase, RuntimeVersion, threadingModel. And the CodeBase is either common file folder (not working) or MyApp's installation folder(working), which is the different locations I put the dll. I thought there would be another sub-key TypeLib under {MYCLSIDs}, since Access only sees the TypeLib and I think there should be some link from the TypeLib to the actual dll, however, at both cases this sub-key is missing but in the second case it is still working. Is there a problem of it?</p>
  
  <p>Secondly I have HKLM\Software\Classes\CLSID\{MYCLSIDs}, this key has the same structure as described above.</p>
  
  <p>Thirdly, the HKCR\{MYPROGIDs}, these are just ProgIDs of my classes</p>
  
  <p>Fourthly, HKCR\Typelib\{LibID}, which includes the information from tlb file, and this ID is from the Assembly GUID of COM component project.</p>
  
  <p>Finally, the HKEY_CLASSES_ROOT\Interface\{InterfaceID}, there is sub-keys named ProxyStubClsid32 with value  {00020424-0000-0000-C000-000000000046}, and the one named TypeLib and the value is my LibID.</p>
  
  <p>It seems the only difference is the CodeBase in the first items (I could be wrong but that is what I see). please let me know if you can see any problem. Thanks!</p>
  
  <p>SECOND UPDATE:</p>
  
  <p>After I install MyLib.dll into the shared folder, the COM calling fails. But if I replace all the CodeBase values for SHARED_FOLDER\MyLib.dll to INSTALLDIR\MyLib.dll, and copy MyLib.dll into INSTALLDIR, it actually works. Vise versa, after I install MyLib.dll into INSTALLDIR(in which case COM is working), I change the CodeBase values from INSTALLDIR\MyLib.dll to SHARED_FOLDER\MyLib.dll, and make a copy to SHARED_FOLDER, this time it fails. So it seems that it is exactly the installation location's problem, which is the opposite to my understanding of COM. And I don't think there is a permission issue for the SHARED_FOLDER(I could be wrong) since it is in a folder that my installer creates.</p>