OpenEdge.Net.pl missing from PROPATH (in the default tty PRO

Posted by dbeavon on 08-Apr-2019 00:17

Is it expected that OpenEdge.Net.pl should be missing from the default PROPATH on windows?  I just installed  a fresh copy of OE 11.7.4 and was surprised by the lack of that library when using the _progres.exe to compile or run programs.

I would have thought it would be standard by now.  Because it was missing, I was forced to find some obscure registry key in order to include the library ( eg. at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\PSC\PROGRESS\11.7\WinChar Startup).

If found the following bug in the KB that is related to "appbuilder":

https://knowledgebase.progress.com/articles/Article/OpenEdge-Net-pl-is-not-added-into-the-PROPATH-in-AppBuilder

... but it doesn't say whether or not it is a bug that the library is missing from the default PROPATH when running _progres.exe.

Any info would be appreciated. Thanks.

PS. For more info about how to modify PROPATH values from the registry, I found the following KB: https://knowledgebase.progress.com/articles/Article/P113237

Posted by Peter Judge on 08-Apr-2019 14:24

PASOE’s conf/openedge.properties file has the PL added.
 
 
I agree that not having  that PL in PROPATH can be confusing. The easiest way to ensure it’s on PROPATH for all clients of an install is to copy it from ./netlib into its parent (so $DLC/tty or /gui or /src), although that needs to be done on each install.
 
 
 

All Replies

Posted by dbeavon on 08-Apr-2019 00:18

Here is the type of message you get when that pl is missing from the propath.

Invalid datatype specified: OpenEdge.Net.HTTP.IHttpClient. Specify a datatype such as 'character' or the name of a class. (5638)

Posted by dbeavon on 08-Apr-2019 00:24

It seems odd that OpenEdge.Net.pl would be missing when there are lots of other obscure propath entries that are added by default, eg:

C:\Progress\OpenEdge\tty\ablunit.pl

C:\Progress\OpenEdge\tty\adecomm.pl

C:\Progress\OpenEdge\tty\adecomp.pl

C:\Progress\OpenEdge\tty\adeedit.pl

C:\Progress\OpenEdge\tty\adeshar.pl

C:\Progress\OpenEdge\tty\dataadmin.pl

C:\Progress\OpenEdge\tty\OpenEdge.BusinessLogic.pl

C:\Progress\OpenEdge\tty\OpenEdge.Core.pl

C:\Progress\OpenEdge\tty\OpenEdge.ServerAdmin.pl

C:\Progress\OpenEdge\tty\prodict.pl

Posted by onnodehaan on 08-Apr-2019 07:26

We have had the samen problem and had to change our setup to include those PL's.

Posted by onnodehaan on 08-Apr-2019 07:26

We have had the samen problem and had to change our setup to include those PL's.

Posted by Peter Judge on 08-Apr-2019 14:02

It was deliberately left off of the default propath – the reasoning being to prevent PROPATH from becoming excessively long.
 
The PL is there (in $DLC/tty/netlib, $DLC/gui/netlib and $DLC/src/netlib) and in PASOE you’ll notice that it has been added to the PROPATH in the properties file.
 
-- peter
 

Posted by dbeavon on 08-Apr-2019 14:14

Can you jog my memory about the PROPATH "properties file"?   Our PDSOE project has a ".propath file", but the OpenEdge.Net.pl is not in there.

My understanding is that it is actually part of the the "standard" tty PROPATH in PDSOE as follows :

It is confusing that the "standard" propath for PDSOE would be almost exactly the same as for _progres.exe with only one exception.

Posted by Peter Judge on 08-Apr-2019 14:24

PASOE’s conf/openedge.properties file has the PL added.
 
 
I agree that not having  that PL in PROPATH can be confusing. The easiest way to ensure it’s on PROPATH for all clients of an install is to copy it from ./netlib into its parent (so $DLC/tty or /gui or /src), although that needs to be done on each install.
 
 
 

Posted by dbeavon on 08-Apr-2019 15:10

Got it.  You were saying PASOE and I kept thinking PDSOE.  It sounds like the point you are making is that this OpenEdge.Net library is beginning to become a standard dependency.  But _progres.exe hasn't quite gotten on the same page yet.

I do like your workaround better than editing the Windows registry.  (Although the registry approach has a KB article on its side).

Posted by Peter Judge on 08-Apr-2019 15:16

As an alternative to futzing with the install, you can manage the set of default PL’s that are added to PROPATH with the -baseADE switch.  
 
 

Posted by dbeavon on 09-Apr-2019 14:27

I'm not that familiar with the ADE.  Can this be used as a parameter in a deployment environment too (ie. in production)?  Or is it primarily used at the time of development (ie. on a developer workstation or build server).

Posted by Ken McIntosh on 09-Apr-2019 15:05

Hi David,

The -baseADE parameter is intended for use as a deployment parameter, which allows specifying a alternative to the ADE code shipped within DLC.  

ADE stands for Application Development Environment, and consists of all of the ABL Development tools, such as AppBuilder, Procedure Editor, Dictionary, Data Administration, etc.  This also includes the OOABL classes from OpenEdge.Core, OpenEdge.Net, etc.

Examples of deployment components from the ADE include OpenEdge.Core, OpenEdge.Net, adm2, adm, just to name a few.  

HTH

Ken

This thread is closed