Dear Rick,
a procedure that has always worked well on server, suddenly returns an error most evenings:
the error exits from this procedure in WwDotNetBridge.prg:
************************************************************************
* wwDotnetBridge :: Init
****************************************
*** Function: Initializes the .NET runtime inside of FoxPro
*** Assume: Calls Load() to actual perform load operation
*** Pass: lcVersion - specific .NET Version or
*** simplified "V2", "V4"
*** llUseCom - if .T. loads .NET Bridge via
*** plain COM interop rather than
*** hosting .NET runtime itself.
*** If you do COM
*** Return: nothing
************************************************************************
FUNCTION Init(lcVersion, llUseCom)
IF !EMPTY(lcVersion)
LOCAL lcShortVer
lcShortVer = UPPER(lcVersion)
DO CASE
CASE lcShortVer == "V4"
lcVersion = "v4.0.30319"
CASE lcShortVer == "V2"
lcVersion = "v2.0.50727"
ENDCASE
this.cClrVersion = lcVersion
ENDIF
this.lUseCom = llUseCom
*** Fail creation if the object couldn't be created
IF ISNULL(this.Load())
ERROR "Unable to load wwDotNetBridge: " + this.cErrorMsg
RETURN .F.
ENDIF
ENDFUNC
If I restart the server the procedure works without error.
Please how to fix it?
Thank you very much for support
Is there no one here anymore?
Check your path and make sure that your application hasn't changed path and can't find the DLL.
More info here:
+++ Rick ---
Dear Rick,
it is a procedure that has been working on the server for years without problems, nothing has changed, in fact if I restart the server the error doesn't come out anymore.
I think it is a problem with the server.
Is it possible that the .Net libraries got corrupted?
How to reinstall them?
Many thanks again!
Very unlikely unless you're out of memory.
Again I would check for a changed path. Wrap the call/instantiation, then write out error information into the trace log.
+++ Rick ---
Dear Rick,
I followed the solutions showed into your article "Unable to load CLR Instance Error", although I don't understand why the application works correctly for years.
- I tried MyApp.exe.config solution
- I tried blocked .NET dll solution (also with Powershell)
- I checked wwdotnetbridge.dll and wwipstuff.dll are in application path
The only strange thing that is found is that by checking .NET version installed with
DO wwDotnetBridge
loBridge = GetwwDotnetBridge()
? loBridge.GetDotnetVersion()
I get .NET version 4.0.30319.42000 as result (wwDotNetBridge.dll version is 6.05).
If I try to install .NET Framework 4.5 setup says 4.5 version is already installed in the system.
The CLR instance error comes out when the application tries to send emails, I think I will abandon this solution in favor of downloading the file.
This seems to me a safer and more lasting solution.
Many thanks again for support, I couldn't work if there was no West Wind Web Connection!
Dear Rick,
I solved the cause of "Unable to load CLR Instance Error" error on our server.
For incomprehensible reasons, the server tries to load the 64-bit version of wwDotNetBridge.dll before sending email of a particular procedure (other email sending procedures in the same executable do not suffer from this error).
Not finding the 64-bit library we get the error.
The issue was addressed by forcing the executable into Windows 8 compatibility.
I share this solution hoping that it will be useful to others as well.
This doesn't make any sense to me. FoxPro is a 32 bit app and so it would never try to load a 64 bit DLL - it has no concept of it. Other applications might, but I don't know why anything but FoxPro would use wwDotnetBridge directly.
Pretty sure there's some other reason than that.
+++ Rick ---
You did not understand.
I have many customers and this is the only VPS that has been experiencing this problem for a few months.
It is not a FoxPro problem and it is not even Web Connection that is being questioned.
I worked on the server all morning with a system administrator, we studied the logs and what you see is that the server makes mistakes every now and then and tries to load a 64-bit library.
Obviously that particular VPS must be abandoned because something has become corrupted.
The solution I wanted to share is the only one that works in this case.