I have learned Cobol, RPG, Fortran, Basic, PL/1, Pascal, C, and Modula 1, but Visual Basic is driving me nuts. There is just so much there and the documentation is overwhelming yet incomplete.
I have a DLL that I got from a HW vendor. In another VB project I just put it (foo.dll) in the same directory as the .sln file and used an Imports statement: “Imports foo”. That worked fine. I have another, slightly more complicated program and the build is complaining that it can’t find the file. I have it in the directory that contains the new .sln file just as I did for the other program; i.e., “Visual Studio 2005\Projects
ame_of_program”. Serach as I might through the documentation I can’t find anything that describes the search path for Imports. What am I doing wrong?
It has been a VERY long time (beta 2, to be exact, as I’m pure SQL these days), but there are a couple of things to look at.
First, if memory serves, imports was just so that you didn’t have to fully qualify every call to various objects. In other words, if you wanted to use a class named “Baseball”, and it was in the “System.Games.Sports” namespace, using Imports with the namespace allowed you to call “Baseball” without using the syntax System.Games.Sports.Baseball everywhere.
To actually use a .dll in your app, you had to add a reference to it, which usually required it to be registered (using regsvr32 or the like), then added as a reference to your project under the Project menu. Once you had the reference, you could use Imports for it’s namespaces just as you would for the built in variety.
As I said, it’s been forever, but perhaps that will either help you down the correct path, or get you started while waiting for a current .NET type to wander in.
I don’t have an answer, but I do have a tip: Google is your friend for any technical issues.
Often I will key in the exact error text (minus my own file names) plus maybe a word or 2 for context (visual studio, etc.) and I typically find the answer on the first page or 2.
I don’t use VB, but I do use Visual Studio. VS will often put the executables in different folders, depending on the type of build. Debug and Release often get their own folders and that is where the exe is running from, so putting the dll in the same folder as the sln file may not be enough. Find where the EXEs are formed and put the dll there. Conversely, you should be able to get away with putting it in \Windows\System or \Windows\System32
Thanks for all the pointers everyone. It tured out that I needed to add a reference to the DLL and still use the Imports to get the declarations. I have been copying the same program over and over, and when I did one from scratch I forgot what I did the first time a few months ago.