D
dbeavon
Guest
@Laura Thanks for the reply. I was afraid you might say something like that. It sounds like the error could mean a number of things. Perhaps you can prioritize OCTA-3502 based on the fact that this message is happening in PASOE, and there are times when the outer _mproapsv agent becomes very unreliable in the context of .Net interoperation. Today I happened to be doing some debugging and the debugger was attached to the _mproapsv.exe process with the Visual Studio (for unrelated reasons) and noticed a few of these "Error loading the .Net runtime" come up in the PASOE agent log while I was doing my debugging. I had originally suspected that it was triggered by a first-chance exception on the .Net side of things - but I never encountered any .Net exception for the whole duration of my debug session. I now suspect that some of the reasons for the message are reasons which are entirely on the Progress side of the fence... and not related to anything going wrong in .Net. It seems to me that the message " Error Loading the .Net runtime " doesn't pass the sniff test . For example, there only seems to be a single appdomain in the entire _mproapsv.exe process . I use .Net for the most minimal purposes (primarily just to use the WebClient in order to call a few REST methods.) The initial usage of the WebClient takes place in the very first moments of the life of the agent process. We can see that the appdomain is loaded with the relevant assemblies right away.... (image)... Given that the appdomain is loaded and initialized many hours (days?) ahead of time, it doesn't make sense for us to be getting the message "Error loading the .Net runtime". I suspect the message is trying to describe a different problem where a new ABL session is unable to be hooked up to the pre-existing .Net runtime. Is there some way to get to the root cause of these error messages? I no longer believe that the cause is on the .Net side. It seems to be a problem within the ABL session. Alternatively, is it likely that this message has a timing-related component to it, and will go away after some number of iterations? Finally, is there documentation about how to use the CLR bridge in the context of PASOE? It seems a bit scary that all ABL sessions are being re-directed to use the same appdomain. An ABL programmer might expect that the CLR calls from one session are isolated from the CLR calls of another session, but that doesn't appear to be the case. Any additional tips would be greatly appreciated.
Continue reading...
Continue reading...