I have a .NET 2.0 COM object that's used by VBA in Excel. It works fine on my dev machine, but when trying to use it on a clean VM workstation I get this error:
Automation error. The system cannot find the file specified.
The dll is registered with "regasm /tlb /codebase mycom.dll" and not put in the GAC. I don't have administration rights on the VM box
Any ideas?
You need to either invoke regasm with the full path to the assembly as the codebase parameter value or put the assembly into some location which is always on the path for searching libraries. Otherwise it will not be found when the client tries to instantiate the COM object.
On windows 7, 64 bit and a .NET 4.0 framework dll (32 bit) that I want to be usable as a COM object for a Microsoft Excel 2010 VBA application, here is what worked for me.
In a cmd shell, run
C:\Windows\Microsoft.NET\Framework\v4.0.<whatever you have>\regasm.exe c:\windows\syswow64\<name of dll> /codebase /tlb:c:\windows\syswow64\<name of dll minus '.dll'>.tlb
You can skip the last part (/tlb:. . .) if you don't want or need intellisense on the machine you are registering the assembly on.
The key hangup I had is that on XP I never had to use the /codebase parameter before but that was the key thing needed before this worked.
I received this "Automation error. The system cannot find the file specified" error after I had created a .NET .dll (v4.0) with the intention of using it in a VB6 application (decorated my class with "ClassInterface" and "ComVisible" attributes, methods with "ComVisible").
I ran "regasm.exe -tlb C:\PathTo\MyDll.dll" but received the above error after adding the .tlb file as a reference in my VB6 application and running/debugging it. Only after adding the "-codebase" parameter to the regasm.exe call and re-adding the .tlb reference did the error get resolved.
Just thought I'd share my experience.
I also receive a automation error. My reference (in MS Access) was to a TLB file. The corresponding DLL file was missing from the folder that held the TLB file and this caused the 'automation error' message to appear. Adding the DLL back in fixed.
I was getting the same error (could not consume the .NET object from legacy VB6 cod on a second dev machine, after it was working on a first machine where I originally wrote it). The .NET DLL compiled and registered just fine - I tried all sorts of combinations - with and without using the "Register for COM Interop" build setting in VS; manually registering via regasm.exe and trying this both with and without the /codebase parameter; tried both enabling and suppressing the COM Visible assembly-level attribute (when suppressing, I set the attribute on the class I need to consume from COM). But nothing worked, I kept getting the same error.
Turns out I had upgraded the DLL output to .NET 4.5 on the second machine, whereas it was originally building a .NET 2.0 assembly. My project had a few references targeting 3rd party Interop DLLs that were running .NET 2.0. When I either updated these references and rebuilt the DLL -or- set my project back to run on .NET 2.0 - my problem was solved. When using /codebase (which VS does automatically) I found that I did not need to put my DLL in the application directory or in \syswow64. Also the MSDN docs state you must use a SN (strong name) for your assembly when using /codebase, but I found you don't have to; you just get a warning from the regasm.exe command line tool.
The point is, from a COM Interop standpoint, be careful about the .NET runtime version of your dependencies with respect to the .NET Framework you are targeting.
