Hi Rick,
I'm deploying a succesfully tested dll (in the test environment) in the production environment.
The following code works fine in the test-environment, but fails in the production environment with a "Type not loaded. Please load call LoadAssembly first." error after the loBridge.CreateInstance() call. When debugging I can see that the loBridge.LoadAssembly("..\RDWsign.dll") call succeeds. Any ideas what could be causing this problem?
TIA, Frits
do wwDotNetBridge
LOCAL loBridge as wwDotNetBridge
loBridge = CreateObject("wwDotNetBridge","V4")
*** Load an assembly from disk
loBridge.LoadAssembly("..\RDWsign.dll")
*!* *** Create an instance of a class - note: No COM registration
*!* loPop = loBridge.CreateInstance("RDWtest")
*!* WAIT WINDOW loPop.HelloWorld()
*** Create an instance of a class - note: No COM registration
loRDWsign = loBridge.CreateInstance("RDWsign.RDWsign")
IF NOT TYPE("loRDWsign")="O"
appMsg("Creation of the RDWsign-object failed:~~"+loBridge.cErrormsg)
RETURN
ENDIF
lcFile=GETFILE("xml","xml-bestand","Sign",0,"XML-file to be signed")
lcSignedFile=JUSTSTEM(lcFile)+"_signed.xml"
DELETE FILE (lcSignedFile)
STRTOFILE(loRDWsign.SignWithCertificate(lcFile,1),lcSignedFile)
fileview(lcSignedFile)
What dependencies does that DLL have and are all those dependencies installed? .NET loads dependencies progressively as they are needed so an assembly load on its own may not mean that everything inside of it will run...
Most likely there's either a dependency in the GAC or on disk that you are missing.
+++ Rick ---
Hi Rick,
Thanks a lot for your quick and very to-the-point response, as always. Thanks to your advice I was able to determine that the dependencies couldn't be the problem, since everything was only dependent on System.
using System;
using System.IO;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Globalization;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Security.Cryptography.Xml;
using System.Web.Services.Protocols;
using System.Xml;
using System.Xml.Schema;
Earlier on I had the problem that .NET 4.6 was not yet installed on the server (I don't administer the server myself).
After checking everything that could play a role in the deployment I discovered that I had built to the X86 CPU. After changing that to "any CPU" the problem was solved.
Lots of karma to you for helping me not to bark up the wrong tree!
wwDotNetBridge has really helped me a lot to keep my ERP-applications (written in VFP) more or less "up-to-date". Thanks a lot!
Frits
Yeah you should always build any code specifically used for VFP with Any CPU
and Prefer 32 bit
.
It doesn't really matter much just don't build for x64
since VFP can't load that as it has to run the 32 bit version of the .NET runtime.
+++ Rick ---