Calling known functions in an unknown DLL

[JB]

I have an aplication which used to be created in Delphi 5. For various
reasons we want to try to recode that in vb .net but the original
application called functions inside one or more dlls that were loaded
dynaically by the name found at run time.

i.e. what would happen is that the application would start, it finds
all the *.dll functions available in a specified subdirectory.
The user would then select one target platform which corresponds to
one DLL from the found DLL list
That DLL is then loaded dynamically and used by the application.

The rationale is that the application then automatically picks up new
target platforms simply by adding the DLL to the appropriate
directory.

I am having problems trying to get this to run in vb .net. I can get a
single DLL to work but have to explicitly name the DLL in the source
code. In delphi I would call LoadLib and GetProcAddress and then cast
the result of GetProcAddress to a pointer to a function which would
then be used by the application. Very simple and it works. This
appears to be impossible in VB .net

Is there any way to achieve this?

[Mattias Sjögren]

>Is there any way to achieve this?

Yes, here's one way

http://www.msjogren.net/dotnet/eng/s...dynpinvoke.asp
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[m.posseth]

i did something simular in the past with VB6
i created several different activex dll`s with different content ( language
dependant versions , plugins ) however with all the same interface
on startup the program searched for the right dll did a create object on it
and it run just fine

well this can also be done with .Net if you investigate remoting you will
see that a simular concept is there also beeing used ( interface based )

regards

Michel Posseth

"JB" <th********@somewhere.else> wrote in message
news:bq********************************@4ax.com...

I have an aplication which used to be created in Delphi 5. For various
reasons we want to try to recode that in vb .net but the original
application called functions inside one or more dlls that were loaded
dynaically by the name found at run time.

i.e. what would happen is that the application would start, it finds
all the *.dll functions available in a specified subdirectory.
The user would then select one target platform which corresponds to
one DLL from the found DLL list
That DLL is then loaded dynamically and used by the application.

The rationale is that the application then automatically picks up new
target platforms simply by adding the DLL to the appropriate
directory.

I am having problems trying to get this to run in vb .net. I can get a
single DLL to work but have to explicitly name the DLL in the source
code. In delphi I would call LoadLib and GetProcAddress and then cast
the result of GetProcAddress to a pointer to a function which would
then be used by the application. Very simple and it works. This
appears to be impossible in VB .net

Is there any way to achieve this?

[Chris Dunaway]

JB wrote:

I have an aplication which used to be created in Delphi 5. For various
reasons we want to try to recode that in vb .net but the original
application called functions inside one or more dlls that were loaded
dynaically by the name found at run time. Is there any way to achieve this?

One way would be to have each .dll implement a certain interface that
defines what method needs to be called. For example:

Public Interface IPlatform
Sub Execute(...)
End Interface

Then a class in the .dll will implement the interface:

Public Class Platform1
Implements IPlatform

Public Sub Execute(...) Implements IPlatform.Execute
'Code to execute here
End Sub
End Class

Then the app that loads the .dll's can get a list of all the .dll's in
the folder, examine each one to see if it implements the IPlatform
interface and if so, instantiate the class and call the Execute method.

One caveat is that loading the assembly to check for the presence of
the interface will load the assembly and it will stay loaded until the
app shuts down. You could potentially load up many of the .dll's and
have them hanging around not being used. In .Net 2.0, there's a way to
load the assembly just for inspecting it so this is not a problem. In
1.1, you can load the assemblies in a new AppDomain and then unload the
AppDomain to unload the assemblies.

Good luck.