.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

  • There is a KB about the fact that the .net open client has no support for the .net standard.

    https://knowledgebase.progress.com/articles/Article/does-openclient-support-net-standard 

    Again, please remember to vote for the idea to add .net standard support! It seems like it would be an attainable goal. I don't see why the openclient should depend on the full .Net Framework anymore. Here is the link to the idea:

    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 

    Finally, I want to point out that some developer at Progress may start working on the openclient in the near future.  See the link ... 
    https://community.progress.com/community_groups/openedge_customer_validation_program/f/277/t/58536# 

    However there was not any mention of bringing .net standard support to the open client.  That is unfortunate and is hopefully an oversight.  At this point in time there very few priorities for the open client that could be more important than making it compatible with the .net standard.

  • Another update... .Net openclient proxies can now be used from .net core 3 applications.  This is despite the fact that the proxies are regular Framework assemblies

    (not .Net standard libraries).

    This is possible with .net core 3.  Preview 7 of .net core 3 is available now as a release candidate.  It is supported in production, per the following announcement:

    https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-7/

    And the new .net core 3 now includes the class OleDbException (for better or worse).  So the old-school .Net Framework proxies that are created from "proxygen" (11.7) can now be referenced within a .Net Core 3 application. It just works!  

    Note that aside from just adding those proxy-related assemblies into a core app, I also had to include a package reference to "Microsoft.Windows.Compatibility".

    I'm pretty happy that Microsoft did all of the heavy-lifting to make this possible for us.  Obviously it would be much better if Progress was to generate standard libraries and formally support them on .Net core, but that might take a while.  In the meantime we are finally able to migrate our client applications to .Net core.

    Here are snippets of my project file.  By targeting core 3.0 and using "Microsoft.Windows.Compatibility", the old proxies could be used without any changes :

    <TargetFramework>netcoreapp3.0</TargetFramework>

    <ItemGroup>
    <PackageReference Include="Microsoft.Windows.Compatibility" Version="3.0.0-preview7.19362.9" />
    </ItemGroup>