.Net openclient usage in netstandard library (eg. from .net core) - Forum - OpenEdge Development - Progress Community

.Net openclient usage in netstandard library (eg. from .net core)

 Forum

.Net openclient usage in netstandard library (eg. from .net core)

This question is not answered

I was able to get quite far in my attempt to use the Progress "openclient" from a custom netstandard library. Unfortunately I haven't gotten past this error: 

Could not load type 'System.Data.OleDb.OleDbException' from assembly 'System.Data'.  It happens when receiving results, after connecting to appserver (see InputTableStreamer.DoStreamResultSet in the namespace Progress.Open4GL.DynamicAPI).

Netstandard libraries are supposed to allow us to put a dependency on any basic .Net framework assembly (that is compatible with the netstandard api).  This only works as long as the assemblies aren't using any extremely unusual components (like OleDb).

Based on what I can tell from reflecting on the Progress.o4glrt assembly there isn't a real good reason for the dependency on OleDb.  It looks like there are a bunch of catch(OleDbException) blocks.  They can be found all over the place but I can't imagine that any OleDbExceptions would ever be thrown.  Would it be possible to get a version of the openclient assemblies for .Net that do NOT have references to OleDb?  Or better yet, get a version that is compiled as a netstandard library instead of targeting the .Net framework?

I was wondering if anyone else has ever attempted to use the .Net openclient from a netstandard library or on .net core.  Hopefully Progress has future plans for the .Net openclient which will allow us to build apps that can be deployed outside of the .Net Framework.  It would be very interesting to hear any news from Progress on this topic.

All Replies
  • Basically Progress needs to support .NET core. It is becoming more and more dominant while .NET Framework is slowing down more with each Version.

    There is an idea for .Net core support: community.progress.com/.../net_core_linux

    But afaik there isn't any statement from progress is they ever want to support .NET core.

  • The openclient is a good place to start fighting that battle.  The entire goal of the openclient is to allow remote integrations that connect to Progress app server.  If you don't support integrations from a netstandard library (ie. a library running on core) then it is not attaining its goal.

    From what I can tell, this could be a really easy fix.  Even if they continue to target the .Net framework (4.6), I would be able to reference their openclient assembly and run it on core - as long as they comment out the odd references to OleDbException.

    Is source code for the .Net openclient available?  I could do some of the leg-work to test it out on core.  I believe the OleDbException is the only problem; but I never got my sample program to execute to completion so I can't be sure.  I tried to use Telerik JustDecompile, but Visual Studio wasn't at all happy with the resulting project.  There were really bad c# statements in there like "uint x = -1;".  I'm not sure how that Telerik tool can sleep at night after generating a line of code like that.

  • Arrays start at 1 and unint start at -1 to make up for it.

  • I've been trying for days now, and no matter which negative number I try, c# won't let me assign it to a uint variable.

         

    I'm giving up for now.  But I did create an entry in the Community IDEAS section.  Hopefully Progress will soon allow the openclient API to be used from a .Net standard library or from .Net Core (UWP).  Here is the link:  https://community.progress.com/community_groups/products_enhancements/i/openedge/please_allow_net_openclient_api_to_be_used_from_within_a_net_standard_library_running_on_either_net_core_or_net_framework 

  • Unsigned integers can't be negative. Instead of using one bit for the sign (0=positive, 1=negative) it will now be used as part of the value. So an unsigned 8-bit means you can get any value from 0 to 255, whereas if you've used it as a signed integer you'll only have 7 bits available for the value, going from -128 to 127.

  • The decompiler is probably not differentiating between signed and unsigned values. -1 is equivalent to the unsigned value 0xFFFFFFFF so you could replace uint x = -1 with uint x = 0xFFFFFFFF to specify the same value in a way the compiler will accept.

  • Shortly there should be a KB article(000092737) about the inability to use the openclient from .Net standard or .Net core.

    Please remember to vote for the idea to allow this type of connectivity:

    community.progress.com/.../please_allow_net_openclient_api_to_be_used_from_within_a_net_standard_library_running_on_either_net_core_or_net_framework