D
dbeavon
Guest
What type of NuGet packages are you talking about? Your question is a bit vague without those specific details. I think you should consider moving more functionality out-of-process. To shove tons of .Net functionality into ABL client-sessions seems unnatural to me. You are right that Progress won't help you with your .Net tool-chain issues (they have plenty of their own work to do for ABL in PDSOE). I've had a couple of .Net bridge tech support issues in PASOE (concurrency issues and memory issues). Being that I'm the first to encounter these issues - after recently starting to use both PASOE and the bridge - it leads me to believe that most customers don't do things this way. Perhaps everyone tries to avoid incorporating .Net functionality *in-process* at such a large scale. I'll tell you the type of CLR stuff that we do successfully in-process from ABL client-sessions.... We send emails, make LDAP queries, use simple namespaces like System.IO, System.Diagnostics, and most importantly use the System.Net.WebClient or System.Net.HttpWebRequest. These last things are the *gateway* to using custom .Net functionality that is hosted *out-of-process*. It is easy for an ABL client-session to interact with local processes that are 100% .Net. You can interact with them via REST or SOAP. I typically host some simple WCF services (from a Windows Service) on the same machine and there is very minimal overhead (~1ms) to make those round-trips ... as long as you are using the .Net versions of the HTTP webclients within the ABL client-sessions. This approach allows the ABL process to do primarily ABL work; but can take advantage of a local .Net process that does primarily .Net work. But depending on your particular Nuget packages, this approach may not work for you. Hope this is clear. Thanks, David
Continue reading...
Continue reading...