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.
.Net Core 3.0 is released.
I tested them again on the RTM version of Core 3.0, and our openclient proxies still work fine. This is despite the fact that they are built from the preexisting proxygen tools.
It would be wonderful if Progress would formally support the preexisting openclient 11.7 proxies in the core 3.0 runtime. (At least for Windows customers. I'd be shocked if their .net openclient worked from a linux machine.)
The only thing that is different today, as compared to when I attempted this a year ago is that Microsoft added the OleDbException class (or some form of it) into .Net core.
During the latest testing, I didn't even need to add the package reference for "Microsoft.Windows.Compatibility". I simply added one for "System.Data.OleDb" and that was sufficient!
<PackageReference Include="System.Data.OleDb" Version="4.6.0" />
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:
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:
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>
.Net Core 3.0 is released.
I tested them again on the RTM version of Core 3.0, and our openclient proxies still work fine. This is despite the fact that they are built from the preexisting proxygen tools.
It would be wonderful if Progress would formally support the preexisting openclient 11.7 proxies in the core 3.0 runtime. (At least for Windows customers. I'd be shocked if their .net openclient worked from a linux machine.)
The only thing that is different today, as compared to when I attempted this a year ago is that Microsoft added the OleDbException class (or some form of it) into .Net core.
During the latest testing, I didn't even need to add the package reference for "Microsoft.Windows.Compatibility". I simply added one for "System.Data.OleDb" and that was sufficient!
<PackageReference Include="System.Data.OleDb" Version="4.6.0" />
Hi David,
.NET Core support is in the backlog for .NET open client. Thanks for testing this out. I suspected it would work, but haven't gotten to try it.
mattB