> Hi, can anybody help please!
>
> I've got an app with a few dlls. When I run the app I get the
> following
> message in a message box:
undname.exe, which is included with VC++ is your friend in cases like this.
Try it out (in your <vs-dir>/VC7/BIN directory).
> The procedure entry point
> ?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@VCAccessGroup@PAC500DB@@$00$0A@UUI_24@Bus2Types@@$OBPE@K@2@XZ
> could not be located in the dynamic link library.
Are you sure you pasted that name correctly? According to undname it's not
a valid decorated name.
> Looking at the library with dependancy walker I find the exported
> symbol is:
> ?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@UCAccessGroup@PAC500DB@@$02$00$0A@UUI_24@Bus2Types@@$0BPE@K@2@XZ
This decodes to
public: static class PAC500DB::CEntityCollectionMap<
struct PAC500DB::CAccessGroup,3,1,0,struct Bus2Types::UI_24,500,unsigned
long> &
__cdecl PAC500DB::CThe500Database::GetAccessGroups(void)
> The main difference I see here is that CAddessGroup is preceeded with
> a V in
[quoted text clipped - 8 lines]
> what the
> dll exports?
A couple of suggestions:
1, Make sure that the DLL and the caller (another DLL or EXE) are compiled
with the same version of the compiler. The fact that the first name above
doesn't decode as a valid name under VC++ 7.1 while the second does suggests
to me that there might be two different compiler versions.
2. Make sure that all #defines (and command-line/IDE defined preprocessor
symbols) are the same when the header file that contains the definition for
PAC500DB::CThe500Database is seen in both modules (the DLL and the caller).
-cd
Scott Langham - 12 Oct 2005 16:00 GMT
Hi Carl,
Thanks for the help. "undname.exe" is an excellent tool. You're right, I
couldn't copy the decorated name out of the message box, so I typed it in. I
put a O where there should have been a 0! The corrected version decoded to
something similar to the exported symbol... except instead of "struct
CAccessGroup" I got "class CAccessGroup".
This confused me for a bit longer because CAccessGroup is defined using
struct. However, it does derive from a class... it appears that this is
somehow affecting the decorated name, but it's different between the
__declspec(dllexport) and __declspec(dllimport) versions.
Anyway, I've changed CAccessGroup so that it's declared as a class instead
of a struct, and this seems to work ok.
The dll and exe are compiled in the same solution using Microsoft Visual C++
.NET 69586-335-0000007-18635.
-Thank-you very much for your speedy help,
Scott
> > Hi, can anybody help please!
> >
[quoted text clipped - 48 lines]
>
> -cd
Ronald Laeremans [MSFT] - 12 Oct 2005 19:18 GMT
> Hi Carl,
>
[quoted text clipped - 70 lines]
>>
>>-cd
Yes that is an unfortunate bug in our compiler. We should not name
decorate a class and a struct differently, but fixing this would
completely break binary compatibility so it is something we cannot do.
Of course the fix in the source is as you already did.
Ronald Laeremans
Visual C++ team