deploying wrapped dlls

  • Thread starter Thread starter csharpdevp
  • Start date Start date
C

csharpdevp

Hello

The application I'm building an installer for uses dlls which were
developed originally in C. Since the application itself is developed in
C#, these dlls were wrapped using SWIG. Initially, the machine
environment variables were set to enable code development; however, I
am facing problem deploying the application. To work with these wrapped
libraries, the application seems to access a specific dll, for
instance, let's say the C assembly name is A.dll, it seems to be making
attempts at invoking its wrapped version, Awrapped.dll.

In the case of my application though, this invocation is producing a
DLLNotFound exception. If the installer sets the environment variables,
then the application is able to pick up the wrapped dlls. If, however,
the path to these wrapped dlls is specified in the application
configuration file as <probing privatePath = "..." />, the dlls are not
found.

I don't have the source code for these dlls. Initially, I had thought
that if somehow I could get access to the source code, I would be able
to strongly name the dlls and then wrap them. Perhaps that would have
allowed me to use assembly binding policies to find the specific dlls.
But now I think even that would not have helped.

Is there a special method for deploying wrapped dlls? Could someone
tell me if this problem is being cause because of the dlls being
wrapped?

Thanks
 
In the case of my application though, this invocation is producing a
DLLNotFound exception. If the installer sets the environment variables,
then the application is able to pick up the wrapped dlls. If, however,
the path to these wrapped dlls is specified in the application
configuration file as <probing privatePath = "..." />, the dlls are not
found.
Click to expand...
I ran into the same problem. "probing" only works with managed DLLs, not native DLLs. You will need to place the wrapped
DLLs into the same directory as the executable, in a directory listed in your PATH, or into a system directory.

Marcus
 
Hello

For the sake of completion, this is a follow up to Marcus's last post
for anyone who might be following this thread. My installer was finally
able to deploy the application succesfully. The wrapped dlls (C/C++
dlls wrapped with SWIG) can be accessed in either of the three ways
listed in the previous post. I'm still not sure why they can not be
accessed by the path specified in the configuration files. However,
that would need further investigation, since I don't know as yet how
SWIG works and generates C# compatible libraries. Anyone who wishes to
share any knowledge on this matter is welcome to do so.
 
Hello

For the sake of completion, this is a follow up to Marcus's last post
for anyone who might be following this thread. My installer was finally
able to deploy the application succesfully. The wrapped dlls (C/C++
dlls wrapped with SWIG) can be accessed in either of the three ways
listed in the previous post. I'm still not sure why they can not be
accessed by the path specified in the configuration files. However,
that would need further investigation, since I don't know as yet how
SWIG works and generates C# compatible libraries. Anyone who wishes to
share any knowledge on this matter is welcome to do so.
Click to expand...
Hi,

SWIG creates a P/Invoke wrapper for your native DLL (http://www.swig.org/Doc1.3/CSharp.html). P/Invoke uses the Win32
function LoadLibrary to load the native DLL. The three ways I mentioned are how LoadLibrary locates a native DLL. The
configuration file is just used by the CLR to determine where to look for managed assemblies and this information is not
"passed" to the LoadLibrary.

Regards,
Marcus
 
Back
Top