views:

40

answers:

3

I have a .NET v2.0 Dll that exposes a few classes to COM. The assembly is called BLogic.DLL

I'm calling these classes from a legacy visual basic 6.0 application. I can generate and EXE file and if I have Blogic.dll in the same folder as the EXE, the program runs without a hitch.

However If I try and launch the same program within the VB6 debugger I get a:

   Automation Error    
   The system cannot find the file specified

I assume when I'm running in the debugger, the PLogic.dll file can't be found. I tried putting it in the System32 folder, and the same folder as the VB6.EXE file, but I still get the same error.

Other facts that may help:

PLogic.dll is NOT a strongly-named assembly. It depends on a 3rd party reference that isn't strongly signed so VS doesn't let me strongly sign it. However the 3rd party functionality isn't being called by the VB6 code, and it is not ComVisible.

A: 

It's been a while so I might be getting this confused but I have some memory that while debugging VB6 supporting dlls should be in the project folder, so in the same folder as the project file.

Edit: Just realised, since it's a COM DLL, the location shouldn't matter since it should have been registered, I can't remember how that works with .NET COM Dlls but I'd suggest trying out Regasm (since it's not got a strong name possibly you'd have to create the Tlib instead and the run Regtlib on that).

ho1
I already ran regasmI used the /tlb and /verbose options
Aheho
also I tried the PLOGIC.DLL in the project folder. Same error.
Aheho
Well, when I got desperate about COM I'd search through the registry for any instances of the DLL and interfaces etc and delete them (obviously being very careful!) and then reboot the PC and do a fresh registration. Not the best solution but sometimes it works. I'd also consider Jan's suggestion that it might be something else failing, maybe could try that by moving your compiled exe and the dll to a new folder and see what happens.
ho1
A: 

Just a thought: the error may be a "normal" exception within the DLL instead of an interop problem. The reason that this exception only occurs when debugging in VB6.exe may be that relative paths (./something.txt) are relative to the VB6.exe when debugging.

Jan Willem B
The error occurs when I create my first object from that assembly. The constructor for that class doesn't reference any external files. In fact, it just sets one private string member. Nothing that would throw an IO exception.
Aheho
+2  A: 

If you don't put your ComVisible .NET assembly in the GAC then you have to use the /codebase option with Regasm.exe

Hans Passant
If that's true, why can I run it successfully when I'm not in the vb6 ide debugger?Secondly, if I can't strongly sign the assembly how can I either put it in the GAC or use the codebase option?
Aheho
The EXE folder is different when you run the IDE. Use the normal Regasm.exe command line, just add /codebase.
Hans Passant
Got it working. Thanks. I didn't realize that you can just ignore the warning you get with the /codebase option when you dont have a strongly-named assembly.
Aheho