Using .NET code from VB6

BrianWren · January 13th, 2005, 12:27 PM

The books all say that VB6 can utilize the output of .NET, and .NET can utilize the output from VB6.

I would like to do the former.

What kind of .NET project do I begin with? (In VB6 it would be ActiveX DLL or ActiveX EXE.)

To grant an entry point to VB6 code, you expose a class; what specifics are needed to provide VB6 an entry point into .NET code?

I need the .NET code to receive several arguments into the entry point. If the entry point is a Function or Sub, that seems easy enough. Are there any poorly documented pitfalls associated with passing VB6 arguments to .NET?

I started one .NET project, saving it on a network server. The result is that I get a warning that the project might not be fully trusted:

Code:

   The project location is not fully trusted by the .NET runtime.
   This is usually because it is a network share or is mapped to
   a network share not on the local machine.  If the output path
   is under the project location, your code will not execute as
   fully trusted and you might receive unexpected security exemp-
   tions.

This is not very meaningful to me. What does it mean to be trusted, functionally?

How do I hook up with a .NET executable from within VB 6? Do I set a reference?

Is there anything else that I need to know?

jaucourt · January 14th, 2005, 07:31 AM

Quote:

quote:Originally posted by BrianWren
What kind of .NET project do I begin with? (In VB6 it would be ActiveX DLL or ActiveX EXE.)

You need to start with a new Class Library project

Quote:

quote:
To grant an entry point to VB6 code, you expose a class; what specifics are needed to provide VB6 an entry point into .NET code?

To 'grant an entry point to VB6 code' you need to expose your class library to COM Interop.

To do this, in the solution explorer right click your project (not the solution!) and go into properties

In the Class Library property pages, go into the Configuration Properties folder, then into the Build item.

Under the 'Generate Debugging Information' checkbox, there is a 'Register for COM Interop' checkbox. Tick this.

You'll now be able to reference your .net dll from vb6, in the way you do for COM dlls. One thing that you will notice is that
intellisense doesn't work for this dll. You can get it working, have a look at http://support.microsoft.com/?kbid=813809 (article id 813809 in case microsoft reorganise MSDN again before you go to the link!).

Something to remember is that only a default, non-parameterised constructor will work in COM. Parameterised constructors are not supported. Therefore, you may wish to create somthing like an 'Initialise' method, that takes the parameters you'd normally want to pass to a constructor.

One problem I encountered was that I (sometimes) got errors when deploying a new version of the .net dll onto a server on which a vb6 production application was running and using the dll. I could only get it working if I compiled the .net dll on the server (you can use the command line tools rather than having Visual Studio .Net installed on the server).

Otherwise, use the regasm command line tool for registering the .net dll on the server.

All-in-all, though, it works pretty well and robustly. I had a VB6.exe using VB.NET.dll for months in a production environment without problem, except for the one described above when I deployed a new version.

Quote:

quote:
I started one .NET project, saving it on a network server. The result is that I get a warning that the project might not be fully trusted:

Code:

   The project location is not fully trusted by the .NET runtime.
   This is usually because it is a network share or is mapped to
   a network share not on the local machine.  If the output path
   is under the project location, your code will not execute as
   fully trusted and you might receive unexpected security exemp-
   tions.

This is not very meaningful to me. What does it mean to be trusted, functionally?

This is an entirely separate issue. It is due to the security features of the .Net Framework, which will not allow you to run an exe or use a dll from a non-trusted network location. Have a look at ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/dv_vstechart/html/vbtchSecurityConcernsForVisualBasicNETProgrammers. htm in the .Net documentation for more details.

It is possible to trust a network location - I can't remember how exactly to do this, have a look in the help. If you have real problems and can't solve it on your own, post another message and I'll try to work it out for you.