Some classes are not exported from MFC extension DLL

[amitd...@yahoo.com]

Hi

I am migrating a product code (originally written in VS2003) to VS2005.
The application is written in VC++ (using MFC) and has mix of managed
and unmanaged classes. It is a desktop based application which controls
an instrument (a device) and interacts with it.

I fixed all the compiler errors and ran the application. I got a
message that "The procedure entry point XXX could not be located in the
dynamic link library AAAA.dll.

Upon using Dependency Walker, I realised that there are at least 5
classes which are not exported from one of the DLLs. (Rest all DLLs are
good). However, inside the code, the classes exported well using
AFX_EXT_CLASS macro before the class name. There are two points to note
here.
1) When the same code was copied as is, compiled and ran on another PC
in a different country (on VS2005), it ran well.
2) The DLL in question here is the one which interacts with the actual
instrument (device) using some third party DLLs.

I am not getting into any good direction. Can anyone guess what may be
happenning? Since the application ran well on some other machine, I
feel the code is ok. It has something to do with some configuration
setting. Can anyone guess?

Thanks in advance.

Amit Dedhia

[Doug Harrison [MVP]]

On 30 Jun 2006 01:46:35 -0700, amitd...@yahoo.com wrote:

>Hi
>
>I am migrating a product code (originally written in VS2003) to VS2005.
>The application is written in VC++ (using MFC) and has mix of managed
>and unmanaged classes. It is a desktop based application which controls
>an instrument (a device) and interacts with it.
>
>I fixed all the compiler errors and ran the application. I got a
>message that "The procedure entry point XXX could not be located in the
>dynamic link library AAAA.dll.
>
>Upon using Dependency Walker, I realised that there are at least 5
>classes which are not exported from one of the DLLs. (Rest all DLLs are
>good). However, inside the code, the classes exported well using
>AFX_EXT_CLASS macro before the class name.

If Dependency Walker reveals the classes weren't exported, how is it they
"exported well inside the code"?

>There are two points to note
>here.
>1) When the same code was copied as is, compiled and ran on another PC
>in a different country (on VS2005), it ran well.
>2) The DLL in question here is the one which interacts with the actual
>instrument (device) using some third party DLLs.
>
>I am not getting into any good direction. Can anyone guess what may be
>happenning? Since the application ran well on some other machine, I
>feel the code is ok. It has something to do with some configuration
>setting. Can anyone guess?

The AFX_EXT_CLASS macro should be avoided, because it cannot be used in
multiple DLL scenarios, where one extension DLL uses another. Try replacing
your AFX_EXT_CLASS usage as follows:

In some DLL header file, which the other DLL headers #include, write the
following, replacing "X" with the name of your DLL, making sure it has a
reasonable chance of being unique:

#ifdef COMPILING_X_DLL
#define X_EXPORT __declspec(dllexport)
#else
#define X_EXPORT __declspec(dllimport)
#endif

Then #define COMPILING_X_DLL only in that DLL's project. This method can be
used by multiple DLLs, a big advantage over AFX_EXT_CLASS, and since the
macro names are unique, they don't conflict. Then you can do things like:

X_EXPORT void f();

class X_EXPORT MyClass
{
...
};

Look in the project's preprocessor options, and you may find the AppWizard
has already defined a suitable COMPILING_X_DLL macro for you.

--
Doug Harrison
Visual C++ MVP