Hi there, I'm working to add e-mail send abilities to my web server instance and having some trouble with loading wwdotnetbridge. I'm running WestWind client tools. I'm getting message:

Server was unable to process request. --->wwdotnetbridge.setclrversion ...wwdotnetbridge.prg error in line 243 Cannot load 32-bit DLL wwipstuff.dll.

This is a dll that is referenced from asp.net so I'm suspecting either rights or path issue. I have put wwipstuff.dll and wwdotnetbridge.dll in the same directory as my DaSHWeb.dll. I also experimented with putting in the root directory of the iis process - same result as above.

I put wwdotnetbridgetest.exe in the same directory as the DaSHWeb dll and it runs fine with the following result: wwDotnetBridge Version :7.15.6.0 c:\inetpub\wwwroot\sync\bin\wwDotNetBridge.dll .Net version(official) :4.0.30319.42000 .NET version(simplified):4.8 .NET Version (Release) :528372 Windows Version :6.2.9200.0 -Release:2004

This particular instance is running in Win10/IIS. The thread is running as an admin at this point to avoid any rights issues.

I also created a dashweb.dll.config file (does it work for dll's the same as exe?) to add just in case, although I assume if wwdotnetbridgetest.exe can run in the directory, it can find the dlls.

Starting to run in circles, so writing for possible troubleshooting ideas. Any help would be appreciated!

Peace, Steve

this is relevant code from my ole class

Define Class DaSHWeb As Session OlePublic

	Function Init
		Set Resource Off   && Best to compile into a CONFIG.FPW
		Set Exclusive Off
		Set Reprocess To 10 Seconds
		Set Cpdialog Off
		Set Deleted On
		Set Exact Off
		Set Safety Off
	Endfunc

	Function testemail

		Do wwdotnetbridge

		lobridge = getwwdotnetbridge()
return lobridge.getdotnetversion()
endfunc

You probably don't have permissions. Check what Identity your IIS Application Pool runs under. Probably doesn't have access to the file...

+++ Rick ---

That's the confusing thing. My app pool is using my login identity right now.

After more testing, here's what I found. I bypassed the server and tried running the dll directly. I've done this procedure on my dev machine (which works fine) and the web server:

I'm loading vfp9 and type the following:

oWeb = createobject("DaSHWeb.DaSHWeb") - OK oWeb.testemail - gives the message from the previous post.

I've tried running VFP as regular and administrator, so I'm not sure what, if any, further rights I can give. BTW - the other functions in this DLL work by running VFP this way for testing, so it has to be an access issue to the supporting dlls.

I also added explicit paths at the top of the testemail func to hopefully alleviate any issue there.

Again, any further thoughts appreciated.

Also - make sure your application pool is set to run in 32 bit mode. The default is 64 bit and wwIpstuff.dll being 32 bit won't run in 64 bit.

+++ Rick ---

OK, I think I'm finally onto the problem. I reduced everything down to a test dll to eliminate the web server, etc. There is a pathing issue, apparently. As long as I load vfp and set default to the calling dll directory, it works. Apparently, setting path statements in the dll is not enough. I will try to set an explicit home directory within the dll and see if that works. I've always been reaching out to a net directory for data access so have never cared too much where I am, but obviously wwdotnetbridge cares 😃

Thanks for talking through with me. I'll send an update as I test more.

DLLs loaded directly in IIS load in the SYSTEM folder context, so yes you need to set the application path explicitly with a fully qualified path (not a relative path).

When creating COM objects that are used in IIS you should always capture the COM server's startup path and immediately add that path the FoxPro path (along with any other relative paths your need.

Something like this in the Init() of the server:

*** Retrieve the DLL location and grab just the path to save!
THIS.ApplicationPath = GetApplicationPath() && ADDBS( JustPath(Application.ServerName) )

*** Add the startup path to the path list!
*** Add any additional relative paths as required
SET PATH TO ( THIS.ApplicationPath ) ADDITIVE

(or add a ComConfiguration() method if the server isn't specifically meant for COM operation)

If you're building FoxPro COM objects it might be worthwhile to look at my very old COM Interop articles in my Article Archive.

The last one is from 2012 (others are older yet, but still relevant):

Calling FoxPro COM Components from ASP.NET Revisited

+++ Rick ---

Thanks for your help, I got it working. It was a simple path problem - finding an excellent article of yours that I had read long ago but apparently not fully absorbed, I added the following to my code:

cDLLPath = ""

function init
		this.cDLLPath = ADDBS(JUSTPATH(application.ServerName))
		SET PATH TO (this.cDLLPath)
endfunc

...likely obvious to most people, but I'm including here to hopefully save a weary searcher some time in the future.