Using an unmanaged external DLL

  • Thread starter Thread starter prodata
  • Start date Start date
P

prodata

I'm moving outside my fairly limited .Net experience here so this may
be a question with a simple, even obvious, answer but if someone would
be kind enough to indulge me...

I want to use a 3rd party DLL to get some data from a set of sensors -
the DLL is effectively an API to the sensor circuitry via a serial
port.

I've got a simple prototype program working so I know that I can
access and use the DLL OK (via ComInterop), but what I'm not clear
about is where the target DLL should be located and how to deploy it.

I'm presuming that this is an unmanaged DLL - if I browse to it from
within the project and try to 'Add Reference' I get an error saying
effectively that it's not recognised as a COM object, which puzzles me
a bit since it's obviously accessible OK to my sample program. But
anyhow, I'm guessing that all I do is to manually place the DLL in an
appropriate folder - perhaps /bin/debug (during development) and /bin/
release (for the final version)?

And then for deployment presumably I manually add the DLL to the
deployment package and allow it to be installed to the main
executables folder of the installed program?

Any comments/clarification much appreciated.
 
Hello,

And how do you use it ? If using Declare statement to access its function it
is not a COM DLL...

--
Patrice


"prodata" <[email protected]> a écrit dans le message de groupe de
discussion :
(e-mail address removed)...
 
And how do you use it ? If using Declare statement to access its function it
is not a COM DLL...
Click to expand...

OK here's just one example of a function declaration:

<DllImport("sensorapi.dll", CharSet:=CharSet.Ansi,
CallingConvention:=CallingConvention.StdCall)> _
Public Function GetYearlyET_V() As Single
End Function

So, I guess it's not a COM DLL, which is presumably why I can't create
a reference.

But the main question still stands: To access the functions contained
in the DLL, I'd guess that the DLL needs to be in the same folder
location as the program executable, ie /bin/debug or /bin/release
during development and in the main program executable folder after
deployment? Is it as simple as that?
 
<DllImport("sensorapi.dll", CharSet:=CharSet.Ansi,
CallingConvention:=CallingConvention.StdCall)> _
Public Function GetYearlyET_V() As Single
End Function
Click to expand...

DllImport and the Declare statement are basically the same thing...
So, I guess it's not a COM DLL, which is presumably why I can't create
a reference.
Correct...

But the main question still stands: To access the functions contained
in the DLL, I'd guess that the DLL needs to be in the same folder
location as the program executable, ie /bin/debug or /bin/release
during development and in the main program executable folder after
deployment? Is it as simple as that?
Click to expand...

Correct. Note thought that in some cases the third party package has its own
installer as it could install several other things it depens on so this is
not necessarily a general rule.

More precisely the search path is documented here :
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Generally when the DLL is shipped as a third party component, you just ship
you app and will find the already installed DLL in the search path (and will
use later versions as they are installed).

And if you can and want to ship the DLL with your app, you generally choose
your application directory to guarantee you'll use this one (as this
directory comes first in the search order).
 
Back
Top