.net dll call from native c++

[sunil s via DotNetMonster.com]

Hi,

I've got a native C++ app which calls a 3rd parth .NET DLL using the
LoadLibrary/GetProcAddress functions. This works fine when the DLL is
located in the app directory, but if I move it out to it's own directory,
then I get a FileNotFoundException. I've tried manipulating the
app.exe.config file's <codebase> parameter, but this doesn't seem to have
any effect, possibly because the DLL does not have a strong name. The only
thing that does work is manipulating the DEVPATH variable/machine.config
file, but I don't think that this is what DEVPATH was designed for. I
cannot guarantee where the app will be run from but I do know that the DLL
will always be found in a fixed directory path. How do I get my app to
read the DLL?

Sunil

 

[Richard Grimes [MVP]]

Hi,

I've got a native C++ app which calls a 3rd parth .NET DLL using the
LoadLibrary/GetProcAddress functions. This works fine when the DLL is
located in the app directory, but if I move it out to it's own
directory, then I get a FileNotFoundException. I've tried
manipulating the app.exe.config file's <codebase> parameter, but this
doesn't seem to have any effect, possibly because the DLL does not
have a strong name. The only thing that does work is manipulating

I am a bit unsure about what you are doing. You have an unmanaged C++
process and you want to load a managed library assembly. How are you
executing the code? How do you load the managed classes in the managed
library assembly? Are you hosting the runtime and using COM interop to
get the class?

Why are you using GetProcAddress? GetProcAddress is for unmanaged
exported functions (__declspec(dllexport)) not for managed, __clrcall,
methods. If the managed DLL is written in managed C++ then you can put
__declspec(dllexport) on a global function that will be compiled to IL
and get access to it via GetProcAddress. When the function is called the
runtime will be initialized, however, DO NOT DO THIS! There is a serious
bug in .NET and Windows that will potentially cause a deadlock. This bug
won't be fixed until Whidbey. You can get round this bug (the mixed mode
loader bug), but it involves separate initialization of unmanaged global
variables and the CRT, and its messy.

As to your question. Fusion is a replacement for
LoadLibrary/GetProcAddress and the sections in the config file are used
to configure Fusion. Those settings have no effect at all on
LoadLibrary. LoadLibrary is configured through the PATH environment
variable and a redirect file (an empty file with the name of the process
and .local as the extension that indicates that LoadLibrary should only
pick up DLLs from the application folder).

the DEVPATH variable/machine.config file, but I don't think that this
is what DEVPATH was designed for. I cannot guarantee where the app
will be run from but I do know that the DLL will always be found in a

DEVPATH is a horrible hack, and as you have said, it is not intended for
doing what you are trying to do. It will be removed in later versions of
..NET

fixed directory path. How do I get my app to read the DLL?

I need more information about what you are trying to do. From, your
description I think that you are trying to call a global function in a
library assembly that contains IL and has been exported with
__declspec(dllexport) if this is the case you are storing up trouble. It
would be better to export a static method from a class, host the runtime
and call the COM Callable Wrapper.

Here's a tutorial on Fusion that you might find useful and explains some
of the issues I have mentioned above:

http://www.grimes.demon.co.uk/workshops/fusionWS.htm

Richard