[RESOLVED] Class Library "Cannot Find DLL Entry Point"

As an experiment, I created a separate library to hold a function, and then tried to call it from within an application.

Normally, would I would expect to see in the code for the function declaration, something like this:

Code:

---

Public Function MyFunction Alias "MyFunction" (ByVal X As Long) Export As Long

---

VB uses the regular convention:

Code:

---

Public Function MyFunction (ByVal X As Long) As Long

---

I know that "export" is critical, as in the first sample, and I believe "alias" is too. I had problems doing this in VB6 and here also. There doesn't seem to be a way to specify an "entry point in VB." How do I do this?

:confused:

That's not how you call managed (i.e. .NET) methods. It's not even how you call COM functions. That is how you call functions that have been explicitly exported from an unmanaged (i.e. not .NET) library. An example of when you would do that is if you were calling a Windows API function.

You already know how to call managed methods because you already do it all the time. Have you ever created a Form and called its Show method. Congratulations, you created an instance of a type that is declared in a separate library (DLL) and called one of its methods. When you create a project, if you want to use types from other libraries then you must reference them. That's how you're able to use types defined in the .NET Framework class library. Take a look at the References page of the project properties and you'll see which libraries are referenced by default.

I added it to the References in the project properties and selected its "namespace" below in the box below. I still get the same error, "Unable to find an entry point named 'MyFunction' in DLL 'TestFunctions.dll." It goes on to reference the data type and line numbers in the main application. I used a "Try...Catch" block with a ToString conversion to place the error in a message box. In my application and library, I used "ULong" The error message contains "UInt64". I would say this is the same thing, but not sure.

I am wondering if this may have something to do with the location of the DLL. I moved it out of its folder after I compiled it. The only thing in the project folder, other than the DLL, was a PDB file and an XML file.

Edit: I changed the Reference to point to the file in the output folder from the compile. Same error message.

If you are making a method that can be used in another .net app, you have no need to use export of any kind. You just have to make sure the place where your code is, is public and the function you wish to call is also public then just call it, .net intellisense will show all available methods.

It also sounds like you do not have Option Explicit/Option Strict turned on, this is a must, have a quick search to see how it works if you have not come across this before.

Example

Code:

---


Namespace SharedStuff
 Public Module modFileAccess

  Public Function GetTempFileName() As String
    Return IO.Path.Combine(IO.Path.GetTempPath, IO.Path.GetTempFileName)
  End Function


 End Module
End Namespace

...

'In the other project
SharedStuff.modFileAccess.GetTempFileName

---

btw. You can add more then 1 project into a solution and make one dependant on the other which makes managing code much easier

Quote:

---

Originally Posted by Grimfort

...It also sounds like you do not have Option Explicit/Option Strict turned on, this is a must, have a quick search to see how it works if you have not come across this before.

---

Yes, they are both turned on. I will give this a try later today.

:)

If you have it turned on, you will get compile errors telling you that it can't find the method. Unless you are adding it as a com reference as opposed to a framework reference, even then I would think it should complain.

A COM reference? In the options, I see something that says, "Make COM visible." I don't use it because I don't know what it means, or what COM is.

The application will still compile successfully. I get the error either way, compiled, or ran from inside VB.

Edit: I tried the sample above. I still get the error. I don't know where you got "namespace" and "module". I used a Class. At the top, it says, "Public Class Class1".

.Net being managed code will not let you (with settings on) attempt to run a method on an object it can not find. In your example you said:

"Unable to find an entry point named 'MyFunction' in DLL 'TestFunctions.dll

Which means you must have a line of code like this:

Dim thing as New MyClass
thing.MyFunction ...

I would have thought this alone would show an error.


Anyways, the example I gave is no different, I have just declared the namespace in the .vb file. If you don't specify in code, it will use the namespace specified in the project settings.
You say you have added the library reference, and added the namespace checkbox, which just saves you having to type it, the principal still applies:

Code:

---


Public Class Class1

  Public Function MyFunction (ByVal X As Long) As Long
    Return x
  End Function

End Class


'In the other app all you should need is this
Dim thing As New Class1
thing.MyFunction(2222)

---

It works now, on my primary computer, but not the older one. I think what I need to do is replicate the folder structure on this computer to match the other one and point the reference to the proper folder. I put the DLL in the System32 folder. What I get is the error reporting service dialog on the other machine. The application never loads.

Edit: Doing as I described above solves the problem. All files were in the same folder. I went back to my internal function which is the same. I simply wanted to know how to do this. I was hoping maybe I would see a difference in execution speed, but that didn't happen. I don't know if it would help to make my function into an internal class. Of course, inline is supposed to be the best.

I appreciate everyone's patience.

.Net does not use the System32 folder. The whole idea is that you can use the framework already installed, and just copy your compiled files onto the machine and run it. You have the GAC which is like a common place to put libraries but I personally never use it, and have only seen it used by 3rd party controls to help link into VisualStudio.

There is no speed difference in calling a method in an external managed library in .Net other then the first time you load the assembly (when it goes to find it). Once loaded thats it, the only I think that speed would be slowed is if you load the assembly with different security rights which adds a layer in the middle (which you get anyway) but the difference is sooo tiny you should never even notice in CPU ticks.

I don't know why, but I get a feeling that you are not using or understanding the managed code part. Its almost like you are coding in something like vb6 hence the comments about COM interop :). If you have the library and your app in the same directory on any .net machine (assuming its compiled in the same/older version of the .net version that is installed) and it should work.

I started programming in 1988. I'm probably twice the age of many people here.

VB6 was about as far as I got with any depth. I purchased the entire VB 2002 .Net package when it came out all those years ago, and it was a major "thud" for me. Everything seemed alien. So, I gave it up and went back to VB6.

There comes a time when it becomes hard to learn anything new. I am at that point. So, if I ask a lot of dumb questions or I seem to not understand something, there's a reason for it. However, I can grasp things very quickly once I begin to understand them. I need to have a foundation of some type as a starting point, then expand from there.

I still have that four-disc set from 2002. I couldn't toss them, even though I really wanted to.

:)