Hi all,


I have created Regular dll statically linked with mfc ( no automation
).
i have written one function which uses MFC classes like CString,Cfile,
etc... This is only exported function. It is not an activex component
nor com dll.
it has following prototye

extern "C" __declspec(dllexport) int fucntion(const CString&
sParam1, const CString& sParam2, const CString&
sParam3)
{

// do some work and return result code
return;

}


Client application which uses that function. ( given .lib in project
setting in MSVC6)



Now my problem is that i have 2 such client application running and
that is on differant locations ( e.g one is running on c:\ and other
is on d:\ ) i want my dll to be in 3rd location ( e.g. e:\ )

Is there any mechanism to import dll by hardcoded path to dll? and
client EXE will load that dll from that path.?

how can solve the path issue for dll? how can i make my client app to
be aware of where my regular dll is located?

i dont want to put dll in same directory as client nor in system
folder.
also dont want to make entry in system PATH variable.

what else option can be? By programming.


when i am trying to run regsvr32 regdll.dll
it says dll is loaded but dllregisterserver failed. may be corrept dll

What should i do? i am stucked...


thanks in advance.

Regards,
Jay

You cannot register a non COM dll(which doesn't export DllRegisterServer func)
Use the win32 api function
HMODULE LoadLibrary( LPCTSTR lpFileName);
and
FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName);

to explicitly load the dll and make your function calls


"Jay Chadderwala" wrote:

If your DLL is a COM server, you can place it at a location of your
choice. It does not have to know where its clients are located.
However, you will surely need to register it.

If you are having problems registering using regsvr32, you have to make
sure that all the dependent modules of this DLL are available at the
time of registration. You can use Depends.exe to see what modules are
needed.

------------
Ajay Kalra
ajaykalra@yahoo.com

Jay Chadderwala wrote:

If it's not COM compliant you can't register it, either use the LoadLibrary
API to load it dynamically. Or rebuild it as an MFC OCX then you can
register it with almost no extra codeing. You might use ATL but there's no
native CString support which is no loss ordinarily but if you've built
something with CString you might have trouble converting to TCHAR