asked on

Create COM interface using ATL dll that wraps existing MFC dll using VC2003

I have created a ATL dll that must wrap an existing MFC dll so that I create a resultant COM interface.
The mfc dll's lib has been properly referenced etc. etc.
The error I get on linking is 2019 which means my call does not match the original.
Here is a typical ATL dll method with its details:
I need to know what I need to do to correct the problem. I want to use implicit linking.

STDMETHODIMP CWrap::CloseDevice(LONG* lngRetVal)
{
//	[DllImport("Device.dll", EntryPoint = "dllCloseDevice", SetLastError = false,
//		CharSet = CharSet.Ansi,
//		CallingConvention=CallingConvention.Cdecl)]
//		static extern string functionname( string key );
	int iRet = dllCloseDevice();
	*lngRetVal = (long)iRet;
 
	return S_OK;
}

Open in new window

drichards

> The mfc dll's lib has been properly referenced etc. etc.
Symptoms would say they are not correctly referenced. You have them listed as additional dependencies in the project properties, and the dll(s) are known to have the desired functions? Perhaps n 'extern "C"' issue?

Are the MFC dll's built in the same version of Visual Studio as is the new ATL wrapper? Shouldn't matter, but just trying to eliminate variables here.

What exactly have you done to set up the references to the MFC dll's?

alexcohn

LNK2019 message says which external symbol is unresolved. Could you post the message in full?

softbee

ASKER

Thanks for both comments:
I wrote this particular dll myself in 2005.
I have checked using 'dumpbin' and the undecorated name I am looking for corresponds to message 2019 which says:
Wrap.obj : error LNK2019: unresolved external symbol _dllCloseDevice referenced in function "public: virtual long __stdcall CWrap::CloseDevice(long *)" (?CloseDevice@CWrap@@UAGJPAJ@Z).
The original was done using VS6 and I am now working with VS2003.
Question:
Is my header prototype correct?
Note the underscore in the error message. That same underscore exists when I examine the original lib using dumpbin. I must also admit that I have never had a clear understanding as to why the underscore should exist.
Does the ATL project require MFC support? Personally I did not think so.

extern "C" { int __declspec(dllexport)dllCloseDevice( void ); }

Open in new window

softbee

ASKER

More explanation:
The setup for the MFC data is done as follows:
I added a lib folder to the project referenced as ..\lib.
I added a include folder referenced as ..\include
The lib file is included in the Linker/Input property under 'Additional Dependencies'
I checked if all this is ok by deleting the lib from the lib directory and making sure I pick up the error that it cant be found.

alexcohn

You should declare the function as dllimport in the header file. The accepted way is to use conditional compilation, as displayed in the attached snippet. The DLL project will have DEVICE_EXPORTS in its preprocessor definitions list.

extern "C" { int __declspec(dllimport) dllCloseDevice( void ); }
 
#ifdef DEVICE_EXPORTS
    #define DEVICE_API _declspec(dllexport)
#else
    #define DEVICE_API _declspec(dllimport)
#endif
 
extern "C" { int DEVICE_API dllCloseDevice( void ); }

Open in new window

softbee

ASKER

Thanks for re-teaching me to look at my problem properly before going public:
I have made the change from export to import and now get the following error:
Wrap.obj : error LNK2019: unresolved external symbol __imp__dllCloseDevice referenced in function "public: virtual long __stdcall CWrap::CloseDevice(long *)" (?CloseDevice@CWrap@@UAGJPAJ@Z)

Since I seem to have lost my common-sense may I ask for one more comment although this has nothing to do with the original subject anymore.

In the meantime I am going to build a one call sample in VC6 just in case.

ASKER CERTIFIED SOLUTION

alexcohn

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

softbee

ASKER

Thanks for pointing out my obvious boo-boo. After 35 years of programming I should now better. Thanks