Linking to an external DLL

[ThermoSight]

Hello again.

I'm back for still more help .....

Sometime in the very near future I expect to begin working with a device that comes with C-callable functions in a .DLL. Can anyone here direct me to the instructions for building an app that links to a DLL ?

I don't have clue 1 as to how to proceed. Up until now, all the files have been in one place: the project folder. Don't have a clue as to how one links to an external dll.

Can ya help an old guy out, here?

thanks.

bill

[Arjay]

Search Msdn for PInvoke.

[ThermoSight]

Hi Arjay.

Thanks for your suggestion. I expect to have the device in my hot little hands perhaps as early as tomorrow, and I'll begin working with the device this weekend.

Say, while waiting for the device to arrive, I was doing my homework by reading the documentation that accompanies the device's associated SDK, and saw that the DLL code is type 'cdecl' although a 'stdcall' version is also shipped and available. Now, that means absolutely N O T H I N G to me, but I hope it means something to someone out there.

Bottom line, my intent is to call on the DLL via C# .... is C# more likely to work with 'cdecl' or 'stdcall' ? If C# can't do either, is C++ an option ?

thanks.

bill

[Arjay]

Search www.google.com for 'stdcall pinvoke' or 'cdecl pinvoke'.

[nelo]

Hi Bill,

To add to what Arjay has said I suggest you look up the subject in MSDN. I might be completely wrong (in which case I apologise) but the way this discussion has gone leads me to think that you've not done much research yourself. In case I'm wrong have a look at this link...http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute(VS.71).aspx

There's a link there that will tell you what to do about 'cdecl' and 'stdcall' as well as brief overview of the what you need to do when accessing native DLLs from within .NET applications.

[ThermoSight]

Gentlemen,

thank you for your input. Nelo, you are correct, Sir. I've done very little research myself, so far. I have M A N Y books here on C++ .NET (including the Holy Grail of C++ .NET: Deitel's "Visual C++ .NET - How to Program") and several books on C# .NET. Several of these books refer to pInvoke in varying degrees of detail. I guess I just need to dig in.

The frame-grabber arrived today, so I am eager to get going. First I must place the finishing touches on my current C# project, then move on to a pInvoke test project, and only after familiarizing myself with pInvoke can I hope to begin working with the device.

Thanks for your help, Gentlemen. It's a little late to begin tonight, but I SHALL follow your links early tomorrow morning. Even before morning coffee.

Thanks again for your help. Hopefully I'll get this pInvoke stuff down in a week or two and then I'll be Ready To Rock.

Best wishes.

bill

[ricky_cpp]

Hi Bill,
Of course you can call external dll in C# and C++. If you are making your own dll then the functions which you want to use in client program are to be defined as dll export and as dll import in client program itself.

Below is an example:

//exampleDLL.dll
extern "C" __declspec(dllexport) t_bool initComm(char* aStr, t_uint aSpeed);

//Client Program
[DllImport("exampleDLL.dll", EntryPoint = "initComm", ExactSpelling = false, CharSet = CharSet.Unicode, SetLastError = true)]
public static extern unsafe bool initComm([MarshalAs(UnmanagedType.LPStr)]string aPort, int aBaud);

//Similarly, you can also call functions of standard libraries
/*use suspend thread from kernel32.dll*/
[DllImport("Kernel32.dll", EntryPoint = "SuspendThread")]
public static extern unsafe Int32 SuspendThread(int handle);



I searched for 'stdcall pinvoke' on google. and first result was link to your thread.

Arjey, today everything can be googled and in such a case we don't need this forum. Being a beginner manytimes (and at times today too), I did not know specific term to google and would spend hours to find a relevant topic. In forums like this we save time by asking people who might have done similar things otherwise help to every single code that one writes in C#/C++ in MSDN help topic.

-Ricky

[Arjay]

Arjey, today everything can be googled and in such a case we don't need this forum. Being a beginner manytimes (and at times today too), I did not know specific term to google and would spend hours to find a relevant topic. In forums like this we save time by asking people who might have done similar things otherwise help to every single code that one writes in C#/C++ in MSDN help topic.I disagree. Part of learning is learning how to find information on your own (through web resources or what have you). If you know how to effectively search the web via msdn, google or other sites like this, at some point you are going to be able to find the answer faster than posting a question to a forum. As far as knowing the specific search terms, I gave them in my second reply. Finally, this forum exists to help folks work through problems. We also subscribe to the 'teach a man to fish' philosophy. As such, we try not to spoon feed the answers, but rather help the OP learn to derive them themselves.

[ThermoSight]

Ricky,

Thanks very much for your help AND for your sample code. I plan to finish my current project on or before Friday, and begin my pInvoke familiarization project Saturday.

One of my books, "Kick Start" by Kate Gregory, shows how to build a DLL in unmanaged C++, and how to call it from C#. I expect to begin with that and build from there.

That however, leads to another question: if the DLL is referenced dynamically, that is at run-time, then the executable has to know where the DLL resides, i.e. what folder it is found in, but at first glance there doesn't seem to be any means of specifying the location of the DLL.

Now, here at the house I have 'n' machines on the network (where 'n' is an integer between 3 and no particular upper limit). If I place the DLL in a folder on the machine I build the application on (say, the \build\debug folder), will the application work if I place the app and the DLL in a different folder on a different machine (say, C:\apps) ?

I dunno .... your guess is as good as mine. (I think I prefer the older-style libraries ... they were so easy to understand and work with)

re my earlier question regarding stdcall v cdecl - I have determined that I should use cdecl. One question down, only a hundred to go.

oh well !

Thanks again, Ricky, ArJay & Nelo. Your help was and is very much appreciated.

No more whining .... I promise.

best wishes to all.

bill

[nelo]

That however, leads to another question: if the DLL is referenced dynamically, that is at run-time, then the executable has to know where the DLL resides, i.e. what folder it is found in, but at first glance there doesn't seem to be any means of specifying the location of the DLL.

Now, here at the house I have 'n' machines on the network (where 'n' is an integer between 3 and no particular upper limit). If I place the DLL in a folder on the machine I build the application on (say, the \build\debug folder), will the application work if I place the app and the DLL in a different folder on a different machine (say, C:\apps) ?
When you use P/Invoke you can specify an absolute path to the DLL. If the path is not absolute, the operating system will look for the DLL beginning at the directory where your application is running. It is a standard procedure to either deploy the DLL and the .NET application to the same 'bin' folder. You can also setup an environment variable for the location of the DLL. Well...there are loads of options.


I dunno .... your guess is as good as mine. (I think I prefer the older-style libraries ... they were so easy to understand and work with)


I've done quite a bit of programming over the years (Pascal, LISP, C/C++, VC++, COM) and now C#/.NET. I cannot see how the old style is better...:) I'm fond of C/C++ particulary with STL but I'll take C# and .NET everyday!!