Messages
Reply
Edit
Delete09:11 am
3P10JPMJV
| From: | Stein Goering |
| To: | Rick Strahl |
We can check the .NET security and permission settings - but remember that in every one of these cases they were using the .NET mail module and loading .NET assemblies with no problem when running under previous Web Connect versions. None of those settings would have changed - all we did to upgrade them was to copy in new versions of the EXE and DLL files.
Were there any changes in the wwstmp coding between 5.64 and 5.65?
--stein
This all seems very weird especially in that is working both for you and me and many other clients.
One difference is that wpipstuff.dll has been compiled with visual studio 2012 - maybe there are some different dll dependencies - quickly checked tho and found that the output size is identical (as 2012 uses the 2010 compiler anyway).
What happens if you change wwipstuff.dll rather than wwdotnetbridge.dll?
The problem isn't in the .net dll I think, but in the wwipstuff loader code I think - that's what's actually failing.
It still sounds to me that there is some sort of security/drive mapping/net access that is triggering the .net security and prevents .net from loading.
+++ Rick ---
The wwDotNetBridge.dll we ended up running is ver 5.64 dated 9/27/12. Reflector shows:
Size: 112128 Bytes
Target Runtime: v2.0.50727
But the one from ver 5.65 dated 12/7/12 has the same target runtime.
I can say for sure that the following sequence of events occurred on at least 2 different systems:
1. An older version of our app was working properly - including calls to .NET assemblies
2. We updated our app to one built under WC 5.65 along with the 12/7 build of wwDotNetBridge
3. We started getting errors when running routines that invoked DNB. Most often Unable to load Clr instance but also OLE error code 0x80131014: Unknown COM status code
4. We downdated wwDotNetBridge to the 9/27 build.
5. We were able to run some of the same routines that had previously thrown errors.
However, the behavior has not been totally consistent as we have gotten occasional .NET related errors after going back to 9/27. This included a new one:
An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy
The above showed up for a short time - then went away without us doing anything. The method in question is now working OK.
Generally it seems like calls to assemblies such as web service proxies are working most of the time. The main problems have been with calls to the .NET mail module. We've had those work on occasion but generally they throw the Clr instance error. Our solution has been to revert to the classic mail mode; fortunately the clients in question don't need SSL/TLS support so we have that option.
Finally I should mention that we're running this same app with no issues on at least 3 in-house systems, using both the 12/7 and 9/27 DNB builds.
--stein
Stein,
That's really strange - there really should be nothing different.
Can you check your wwDotnetBridge.dll and open it with Reflector to check what .NET runtime version it's compiled in?
Another thing - there's a dependency on Newtonsoft.Json.dll - this shouldn't be required, but there is a new assembly reference compiled into the new wwDotnetBridge.dll - it works for me here without that, but maybe on .NET 2 it somehow tries to load that assembly?
Try copying that dll on the problem servers and see if the problem goes away?
+++ Rick ---
No, we require Server 2003 or higher.
We have found that the issues go away if we go back to the 9/27/12 release of wwDotNetBridge.dll.
--stein
Stein -
Are the customers having this problem running under Windows 2000?
- Mike McDonald
Software Design of Kentucky
Just noting that another customer is also reporting this error since upgrading to the WC 5.65 instance of our app.
There seems to be a consistent pattern of .NET interop issues since that release...
Since upgrading our app to WC 5.65, a couple of customers have reported errors in routines that use wwDotNetBridge. It's from the line this.load() in wwDotNetBridge::init
Unable to load wwDotNetBridge: Unable to load Clr Instance.
We've verified that they have the latest DNB DLL (dated 12/7/12) They both have .NET versions V2.0.50727 and V4.0.30319
Am fairly sure that in both cases the code in question was working before we upgraded.
--stein
