Keith G Hicks wrote:
OK. It's working. Thank you for all the notes on this (Onur too). But I have
a couple of questions.
First, some samples I found earlier had this sort of thing in the calling
exe's code:
Imports FNTNoticeImport.GetRoot
Module GetRoot
Declare Auto Function GetMyRoot Lib "C:\My
Projects\ImportEmailedNoticesIntoFNT\TestDLL\bin\R elease\TestDLL.dll" (ByVal
x As Double) As Double
End Module
Does adding the "reference" to the project mean that's not necessary?
Yes.
Adding references and creating objects is the ".Net way" of using
..Net-created dll's. The "Declare" method, above, (and it's newer
equivalent, the "DllImport" Attribute) are used to access native Windows
dll's. Unless you need to reach into, say, the Windows API, I'd
recommend you avoid them and stick to references.
I did it as you suggested below and commented out the above and it
all worked. I'm guessing the idea above might be for older types
of code (vb6 maybe?)?
Actually, more like C++ and even Assembler!
That didn't work anyway because I kept getting entry point errors.
It's quite difficult to build a native dll in .Net. Not impossible, but
more often than not just not worth the effort.
Second, since I had to browse to the reference, and it seems that the path
to the dll is stored in the project, how do I deal with that? Does it just
"look like" a hard coded path? Since the compile process puts a copy of the
dll in the release folder, does it expect the dll to be in it's same
folder?
At run-time, it will load this dll from the directory that contains the
program that needs it so deploy both .exe and .dll alongside one another
and things should work.
What about calling the dll from another program as I mentioned I
need to do? Can I register the dll on a machine and call it from other
machines without them having to know exactly where it's located?
Ah; now that's one of the "next steps" - adding your Assembly to the
Global Assembly Cache. For that, you need to make some changes to your
dll project:
(1) "Fix" the Assembly version.
In the AssemblyInfo file (or wherever your version of 'Studio sets it),
set the Assembly Version to a fixed value, say "1.0.0.0". Doesn't
matter /what/ value, just get rid of those asterisks ("1.0.*")! The
asterisks cause the Assembly Version to be "generated" each time you
open the project and, when the GAC is involved, a different assembly
/version/ effectively means a totally different /assembly/.
(2) Strongly Name the assembly.
For this, you need a Strong Naming Key (.snk) File. Create yourself one
and put it in a /very/ safe place. IMHO, you should use the /same/ .snk
file for every Assembly that you want to Strongly Name. (I'm afraid
it's that long since I created mine, I've forgotten how!).
Include this in your project settings and rebuild the assembly.
(3) Use GacUtil to "register" it.
Find gacutil.exe (part of the SDK) and feed your dll into it:
....\gacutil.exe -i <name>.dll
(Even better, set this up as an "External Tool" in studio - saves you
popping up DOS prompts all over the place).
With all that done, remove and re-add the reference in your .exe project
- you should notice that the local copy of the dll /disappears/. All
your programs should now go to the GAC to load your dll.
If you rebuild the dll assembly, remember to re-add it to the GAC - if
you don't, then adding a reference to it will go back to the original,
local copy way of working.
Of course, deploying the dll assembly to (and registering in on) your
client machines might prove a little interesting ... ;-)
HTH,
Phill W.