开发者

VB6 to COM-callable wrapped .NET - problems finding .NET libraries

开发者 https://www.devze.com 2023-04-06 15:14 出处:网络
Premise: Wrote a COM-callable wrapper (CCW) written in C# to be called by VB6 code. The C# code has开发者_运维知识库 .NET libraries (third party) that it must utilize.

Premise:

  • Wrote a COM-callable wrapper (CCW) written in C# to be called by VB6 code.
  • The C# code has开发者_运维知识库 .NET libraries (third party) that it must utilize.
  • The wrapped C# class instantiates fine, raises events properly, takes method calls properly.

Problem:

  • The VB6 code, when running the C# code, gets an error when the C# code attempts to access the additional .NET libraries mentioned above.

Process tested:

  • C# wrapped code completed.
  • VB6 code written, references the COM dll created.
  • "File not found..." error received when the C# code tries to access the .NET libraries from inside itself.
  • Copied the third party .NET libraries into the main folder of the VB6 code (also into system32 folder).
    • Still "File not found..." error.
  • Wrote a C# Windows Form test project. Referenced the C# wrapped code.
    • Received the same error as the VB6 code.
  • In C# Windows Form test project, referenced the .NET libraries used by the C# wrapped code.
    • The program ran just fine.

Conclusion/Question:

  • Can VB6 call/use a com-callable wrapped C# program that references other third party .NET libraries?


I've done this with tons of third party libraries and as long as the third party library DLL's are in the same directory as your C# DLL's there shouldn't be a problem.

  1. Copying them into the same directory as your VB6 code will do nothing, the effective directory of VB6 code when running the in VB6 debugger is %ProgramFiles%\Microsoft Visual Studio\VB98, so the code running will have no visibility of that.
  2. The system32 directory has nothing to do with DotNet dll's (the only DLL's they would affect is PInvoke'd dll's and you say you add a reference so that isn't the case).

Adding the third party library to the GAC should fix things, however that is not necessarily possible/easy due to the need to sign the DLL. So just make sure the Libraries you are referencing are in the directory of YOUR library and that VB6 is actually referencing that version of your library (Debug/Release whatever what last compiled). You may want to hand RegAsm the library to make sure the correct library is Com Registered.

So to sumerize, suppose your source code looks like this:

c:\projects\vb6project
c:\projects\c#project

And your project is set to Debug, the third party libraries should be in:

c:\projects\c#project\bin\Debug

When you actually want to distribute the application, make sure that ALL the libraries are in the same directory as your VB6 exe.


This will mirror somewhat the answer by Kris Erickson.

First, for my usage which solves these problems, I did not use the GAC. Assuming that my VB6 application is in c:\program files\mycompany\vb6app.exe, I placed the COM-friendly .NET dll (lets call it net4vb.dll) in the folder with the executable. I then regsiter that dll there with RegAsm using the /codebase option. Finally, I place the .NET assembly that I'm wrapping or using (lets call it purenet.dll) in that folder as well.

At this point, vb6app.exe should run with no errors.

It is important to note that if you select the "Register for COM Interop" in Visual Studio then it will overwrite the registration you did above. So do not use this option. Stick with the command-line tools only for this.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号