.NET Framework with PASOE

Yes, PASOE works with .NET in the MS-Agent. Which version of OE are you running and what is the .NET framework.

OE 11.7.1 with .NET Framework 4.6. In looking at the logs closer it works for the first 4 agents and then the fifth agent produces the errors.

Is there an answer to this issue.  We are running 11.7.2 and I am noticing the same sort of message on SOME threads, but not all.

18/02/15@10:10:16.436-0500] P-015928 T-002396 1 AS-7 -- (Procedure: 'process-web-request myProg.p' Line:9308) Error loading the .NET runtime. (14081)

[18/02/15@10:10:16.436-0500] P-015928 T-002396 1 AS-7 -- (Procedure: 'process-web-request myProg.p' Line:9308) The OpenEdge GUI for .NET is disabled for this session; the required .NET Framework version is not installed. (14798)

[18/02/15@10:10:16.436-0500] P-015928 T-002396 1 AS-7 -- (Procedure: 'process-web-request myProg.p' Line:9308) Static instance failed to load. Cannot reference class MyUtils. (14631)

Additional note:  I only see this on the /web transport, and so far only with the CompatibilityHander.

Its a long shot, but intermittent problems like this may somehow be related to code page conversions.  Perhaps .Net and ABL are having integration issues of some type.

I saw the same .Net error message in the release notes for 11.6; there is some relationship to the code page that was used. see link:

https://community.progress.com/community_groups/openedge_general/w/openedgegeneral/2744.openedge-11-6-release-notes

The hard part may be to reproduce the issue *consistently*.  We've had code page error messages in our PASOE logs in the past but don't seem to get them anymore.  I was never able to isolate a consistent reproducible for this:

[17/11/22@12:33:21.133-0500] P-012800 T-008724 1 AS-7 -- The client's code page in unknown. No code page conversions will be made. (8031)
[17/11/22@12:33:21.138-0500] P-012800 T-008724 1 AS-7 -- The client's code page in unknown. No code page conversions will be made. (8031)
[17/11/22@12:33:21.146-0500] P-012800 T-008724 1 AS-7 -- The client's code page in unknown. No code page conversions will be made. (8031)
[17/11/22@12:33:21.149-0500] P-012800 T-008724 1 AS-7 -- The client's code page in unknown. No code page conversions will be made. (8031)

We've changed our code around significantly since then.  One thing we stopped doing is using the QUIT statement to restart our so-called "session-managed" client activity.  That was problematic for us.  Perhaps it negatively impacted the SESSION code page.  It would be helpful if there was additional logging that was specific to code page operations in an ABL session. 

Good luck, David

(FYI, I am currently using the .Net framework successfully from PASOE on Windows; and I don't see the code page errors in PASOE that I had seen in the past.)

This morning I tried adding '-preloadCLR' into the ABL Web App 'Agent Startup Parameters' just for fun.  The behavior is the same.

Essentially, one thread on the agent will throw the error relating to a static class, and looking at the 'Stack' for the agent thread I see that the class is not loaded.  All other threads for the agent DO show the class as loaded.  It always appears to be the first thread that is accessed that throws the error.

Based on the behavior is does not seem like this issue is related to the static class, as it runs fine on other threads under the agent. These classes and programs all work without issue under WebSpeed Classic and on PASOE configurations running the apsv transport.

Digging further, I noticed that the static class that was failing was calling a method in the constructor, and that method referenced some .Net code (Progress.ClrBridge.AssemblyStore to be specific).  If I remove the call to that method from the constructor, the issue goes away.

I simplified the code down to a method as follows (simply System.Math call), to see if this was specific to Progress.ClrBridge.AssemblyStore.  Adding a call to the following method in the constructor causes the error to occur.  Again, only on the first thread accessed.

METHOD PUBLIC STATIC VOID doDec():
    DEFINE VARIABLE vDec AS DECIMAL NO-UNDO.
    vDec = System.Math:Ceiling(3.5 * 100 ) / 100.    
  END.

If you execute the logic in the method directly in the constructor, the error does not occur. Only when calling a method from the constructor.

Is this a known issue in 11.7.2?

It may be possible to remove the method call for the static class in question, but why should I have to make this change? We'd rather not need to review every class to make sure constructors aren't calling methods that access .Net resources.

Has this been reported to Progress tech support yet?  We use a bit of .Net interop in our ABL and may use it more in the future.  It would be nice to avoid these bugs if possible.

I found this KB but it probably isn't yours.  It looks like it predates OE 11.7:

knowledgebase.progress.com/.../000056447

FYI, the intermittent errors loading the .Net CLR bridge were hot-fixed for us by Progress.  They don't seem to be happening anymore (so far so good but it has been only one day).

The fix is available for 11.7.4.  Presumably it will make it into the next SP (11.7.5) too.

Was hotfixed for us in 11..4.

Oops.  11.7.4. (.007 I believe)