Hi!

I have a main program and several (from 3 to 300) little dll's. The main program has to call about 5 of the dll's functions. At devel time I know the names and parameters of the functions, but not the dll's name (so that's a variable). What I'd like to make is

dim d as string = "out.dll"

and then doing something like

<DLLImport(d)>.Func(4, 12)

All of the dll's knows that same 5 public functions, but all of them produce a different result. Both the main program and the dll's are written in VB2005.

Thanks for any help in advance

: Hi!
:
: I have a main program and several (from 3 to 300) little dll's.

300... talking about overkill ;)
Is there no way you can do with one DLL and a data file? :P


:The main program has to call about 5 of the dll's functions. At devel
: time I know the names and parameters of the functions, but not the
: dll's name (so that's a variable). What I'd like to make is
: dim d as string = "out.dll"[/code]: and then doing something like

: <DLLImport(d)>.Func(4, 12)

: All of the dll's knows that same 5 public functions, but all of them
: produce a different result. Both the main program and the dll's are
: written in VB2005.
:

I don't have VB2005 installed on this computer, so I can't check.

There is an API called LoadLibrary() and GetProcAddress() that can be used to get C-style functions from DLL's. But those are C dlls and I highly doubt VB2005 exports them as such.

How did you expose the functions? Are they in a Class, or in some kind of public module?

Best Regards,
Richard

The way I see it... Well, it's all pretty blurry

: 300... talking about overkill ;)
only one of them is used at any given time, the user can "select" which one.

: Is there no way you can do with one DLL and a data file? :P
well, I could but in that case, with every addon, both the dll and the data file would need to be updated. the later would soon reach a size of a few hundred MBs (there are some images embedded too), and the complexity of the previous would grow over what I can see throu. I really wish to handle the data and it's logic together, separated from the other data and the main prog

: How did you expose the functions? Are they in a Class, or in some
: kind of public module?
in a class that implements an interface known by the main program.

: in a class that implements an interface known by the main program.

Perhaps the VB2005 equivalent of CreateObject?
Like I said, I can't look into it right now, but try and find a similar function in the .NET library.

Best Regards,
Richard

The way I see it... Well, it's all pretty blurry

: : in a class that implements an interface known by the main program.
:
: Perhaps the VB2005 equivalent of CreateObject?
: Like I said, I can't look into it right now, but try and find a
: similar function in the .NET library.
thanks, it worked. the final solution was:

dim bCom as ICom = System.Activator.CreateInstanceFrom("d/PrjA.dll", "PrjA.Comm").Unwrap()

Now a second thing. The small dll's are in a different directory than the exe file. Both of them depend on a common dll file (let's call it c.dll), which is a project in the same solution, and VS creates a copy of it for both of them, in their own directories. How can I tell the main project to search for this file in "d/c.dll" instead of "c.dll" (this one is at the References)?

A thought:

Create a seperate solution for the DLL. Add the DLL project. Create the DLL file.

Then in both projects, reference the DLL using the Reference menu.

Best Regards,
Richard

The way I see it... Well, it's all pretty blurry

I've tried, but it still was looking for it in it's own dir. :(

: I've tried, but it still was looking for it in it's own dir. :(

Normally when you compile a DLL, it registers the DLL with Windows components, so the path is not an issue.

Did you create the DLL, then go to the other app and in the Reference menu select the DLL (check if the directory it displays there is correct) and then use the referenced DLL? And did you make sure the path isn't hard-coded in your app?

Best Regards,
Richard

The way I see it... Well, it's all pretty blurry

: Did you create the DLL, then go to the other app and in the
: Reference menu select the DLL (check if the directory it displays
: there is correct) and then use the referenced DLL?
yes, this far is sure. if the path wouldn't be good, it wouldn't even compile itself. I've also tried it so that the dll I referenced was in the subdir of the app's output dir, exactly where it was supposed to be, and even then the VS either created a copy of it, and crashed when I removed the copy, or didn't create a copy, and the app crashed.

: And did you make
: sure the path isn't hard-coded in your app?
In the app? I don't even know how can I hardcode it. If I knew, then my problem would be solved. With every previous app I've written with VS, every dll I referenced to in a program was put right next to it during compilation time, in it's own directory, and when I removed it or put it away, the program failed to start (just like now, but so far it wasn't a problem). So I was under the impression that VS, by default, links every referenced dll so that it has to be next to the program, and I am searching for a way to alter this default behaviour. But if you could tell me how to hardcode the path of a referenced dll into the app, that'd also be perfect.

Well you shouldn't even hardcode it.
The idea is that when you reference it, it doesn't matter what directory it is in, as long as the DLL has registered with Windows.
When you compile your DLL project, it should register and thus be location-independant.

At your main app solution, is the DLL project still included?
I suggest you remove any sign of the DLL project from the main project and do it just with the reference.

Best Regards,
Richard

The way I see it... Well, it's all pretty blurry

I did it all. New solution with the dll as a reference, new solution with the project as reference, it doesn't want to do that. Well, never mind, i'll try to solve it another way...

Thanks for the help.

Best regards,
Thomas