>Hi,
>
>I am getting an error on the line SetClrVersion() below (this is one of the functions in wwClientTool).
>
>

>PROTECTED FUNCTION SetClrVersion(lcVersion)
>DECLARE Integer SetClrVersion IN WWC_CLR_HOSTDLL string
>SetClrVersion(lcVersion)
>ENDFUNC
>

>
>The error says
>

>could not find entry SetClrVersion in the DLL
>

>
>The DLL is in the PATH.
>
>But when I place the DLLs in the folder where the program is executed, no error. Does it mean that DLL always MUST be in the folder for this call?

Check where WWC_CLR_HOSTDLL is #defined, I guess somewhere in wconnect.h or some such file - it may contain a path. So either recompile the ww stuff to include a path you can use, or put it in some place where the COM mechanism can find it (windows system folder, or where you already put it - the app's folder).

In most of the cases, a COM object has no clue of any folders you may have used while making it; it's most probably instantiated with default folder somewhere in your private folders (%appdata% or thereabouts), and it may actually find a wrong version of the dll in one of these places. Since the apps own folder is searched before the other default locations, you already circumvented that mechanism in a way that works for you.

You may use _vfp.ServerName to get the full path to the location of your .exe or .dll, and then extract that path and use it to find other components that you install in that same folder or below it - which I've found is one reliable way to find those other files. Just don't make any assumptions on the current folder, because there are no guarantees to that. If your app is running under IIS, your DLL is created by the user to whom the application pool is assigned (in "run as" setting), and then it's that user's %appdata% or some such folder. You are better of if you (write your COM object so that you) don't care where that folder is.