08:08:57 AM
3GZ0HGV88
It has to be on the local machine, as far as I can tell.
At least, that's the way it was solved for me. I had to copy the dll onto each users machine in the app folder. I tried to point to a common shared folder back on the file server, but it would not load the dll from there.
Geoff,
I can assure you that as long as FoxPro can find the DLL it should work.
If you're getting errors due to file location problems then the files cannot be found. If you can consistently make this fail, you should try FULLPATH("wwdotnetbridge.dll") to see where exactly FoxPro is trying to go when it fails. Note there are also two dependencies: wwIpStuff.dll (to load the .NET runtime) and wwDotNetBridge to provide the .NET Proxy.
Pay special attention to partial paths in your path AND where your current path is at.
I would echo out:
MESSAGEBOX( FULLPATH("wwdotnetbridge") + Chr(13) + SET("PATH") + CHR(13) + SYS(5) + CURDIR() )
to see exactly what's going on.
I guess my first question would be is: Why do you have to change path to find the DLL - the ideal location is in the app's startup folder in which case it should always be found by FoxPro assuming you don't explicitly change paths.
Another thing to keep in mind that there are special rules for loading .NET assemblies from network locations. THere's a topic in the help file for wwDotNetBridge that talks about this. This doesn't sound like your problem but it's a possibility:
http://www.west-wind.com/webconnection/wwClient_docs?page=_36e0qlogr.htm
Hope this helps,
+++ Rick ---
I did double check; I have added the startup directory to the path. Now it errors out the first time I run it, then works fine. I can't imagine why that would happen.
The only thing I have gotten to work consistently is changing the current directory, then changing it back. I'm not thrilled with this solution, but it works.
You better double check your path and make sure that the path is valid.
Especially make sure if you have relative paths that the paths evaluate properly *based on your current directory* especially if you are changing paths in your application.
If you're never changing paths or always reverting to a fixed path (which I would highly recommend for any desktop application) then puttin the dlls in your startup path is the best choice.
+++ Rick ---
Thanks for the quick response! The directory is already in the Path, so I'm still not sure what's going on here, but I managed to get it working by temporarily changing the Default directory to the path that holds the DLL's, and then changing it back. Not the cleanest solution, but it works.
Hi Geoff,
The path is not fixed - but the DLLs need to be in the FoxPro path or the current directory of the executing application (ie. in SET("DEFAULT") or SET("PATH")).
I don't think the documentation says anything about the DLLs going into a specific folder. The recommendation is that the DLLs go into your application's install folder and you ensure that the FoxPro path is pointed there (in case your application actually changes the current directory).
+++ Rick ---
I have implemented the new wwSMTP class to send emails from my program. I use it from two places. My intention is to put the wwIPStuff.dll and the wwDotnetBridge.dll in the program directory. I see in the documentation that those files should go in a subdirectory called "Classes".
I tried to do it the way I wanted, and it worked fine from one place in the program, but in the second place I got an error saying the the wwDotNetBridge.dll could not be found. I find this baffling. I traced through the source code from both places; the process is exactly the same, all the same lines of code are run, but one works and one doesn't.
When I put both DLL's in a subdirectory called Classes, everything works. This is not acceptable for my solution. How can I get the code to see the DLL's where I need them to be?
