OpenEdge and NuGet Packages

Posted by Neil Treeby on 29-Mar-2019 12:36

Has anyone had any thoughts on how to organize NuGet packages required for ABL .NET code?  The automation built in to Visual Studio that automatically gets the latest version on a build is not, of course, present outside of VS.  I need to use the standalone nuget.exe to install packages, find the DLLs after they're installed, copy them to my Assemblies folder (or GAC them), and manually add them to my assemblies.xml.

I know it's a reach to expect Progress to develop this kind of functionality, but maybe someone out there has already been through this and has some tips and pointers.

All Replies

Posted by dbeavon on 29-Mar-2019 14:08

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

Posted by Neil Treeby on 29-Mar-2019 14:19

I'm not looking to leverage lots of third-party .NET functionality.  Like you, I'm looking at using .NET to do basic stuff that is included in the framework.  Email is one of them, and this is where NuGet comes into the picture.

Microsoft recently declared that System.Net.Mail.SmtpClient is obsolete (docs.microsoft.com/.../system.net.mail.smtpclient, which links to github.com/.../DE0005.md), and are encouraging folks to start using the MailKit/MimeKit NuGet package instead.

Since I'd rather use .NET than continue to use CDO, this essentially forces me to use NuGet since I don't see MS incorporating MailKit/MimeKit into .NET any time soon.

Posted by dbeavon on 29-Mar-2019 15:25

I'd probably use an out-of-process SMTP client (write the mail body and attachment files to SESSION:TEMP-DIRECTORY and then send those file paths over to the other process to do the emailing).  If the other process was already up-and-running, eg. as a local windows service, then you could send emails in minimal time (probably in under ~10 ms).  If you choose to launch another, fresh .Net process and use command line arguments to send the email then that would probably add a second.

I found that one thing leads to another, and it is likely that you will need other types of .Net functionality to be hosted out-of-process as well.   If you already have a windows service process which hosts these "micro services", then you can add to them whenever your requirements expand beyond just sending emails.

(Note that if you have ever used the Progress "JMS generic adapter" you are essentially offloading all the java-JMS-related work to another "symbiont micro-service" as well.)

We currently use the standard SmtpClient, and send emails from directly within the ABL client-session.  They say it is deprecated because it was designed poorly, but for very simple SMTP operations, it probably doesn't matter much (unless they ever remove it from the framework).  And if we ever needed to do some more advanced stuff, then we would probably invest in creating an out-of-process option.

Alternatively you hinted about using the GAC.  It would be fairly easy to create a installer package from a "setup project" in VS that will put your nuget dependencies into the GAC.  But they would need to be signed.  You could run it on the development workstations as well as your deployment machines.

Posted by tbergman on 29-Mar-2019 15:27

If you're looking for robust mail functionality that will work using the Progress CLR bridge, look at what's available from Chilkat. It's not free but their tools are excellent and well worth the minimal cost.

https://www.chilkatsoft.com/

I have no relationship with this company,

Posted by goo on 01-Oct-2019 16:28

I have tried to make Chilkat avail in the development, but getting rejected when trying to load it. Why?

Sendt fra min iPhone

29. mar. 2019 kl. 16:28 skrev tbergman <bounce-tbergman@community.progress.com>:

Update from Progress Community
tbergman

If you're looking for robust mail functionality that will work using the Progress CLR bridge, look at what's available from Chilkat. It's not free but their tools are excellent and well worth the minimal cost.

https://www.chilkatsoft.com/

I have no relationship with this company,

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by tbergman on 01-Oct-2019 16:42

A very common problem with downloaded .Net DLL’s is a Microsoft security flag that needs to be set.
 
Using Windows explorer, right click on the dll and choose Properties. See if there’s an “Unblock” choice. If there is, unblock it. Now try to add it to the assemblies file using dev studio. If you’ve already tried and failed, restart dev studio and try again. There’s a picture of what this looks like at www.chilkatforum.com/.../could-not-load-file-or-assembly-chilkatdotnetdll-or-one-of-its-dependencies-the-specified-module-could-not-be-found
 
Tom
 
 
 

Posted by goo on 01-Oct-2019 19:08

You were right Tom, unblock, and x32 did the trick.
 
//Thanks !!
 

This thread is closed