D
dbeavon
Guest
Have you tried it yet? You may be able to get it working on .Net core 3 or later. I would recommend using an intermediate .Net standard library to interact with the Progress.o4glrt (openclient stuff) . Then use your standard library from the .Net core application. This was working for me thanks to a lot of heavy-lifting by Microsoft. See the blog: devblogs.microsoft.com/.../ Section : "Reference .NET Framework libraries from .NET Standard" There have been several discussions about this already. See: community.progress.com/.../56089 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 This didn't initially work at all. But once .Net core 3 came out I was able to get things working. This was thanks to Microsoft and the evolution of the .Net ecosystem. (Prior to .Net core 3 you would encounter strange issues related to the unnecessary use of System.Data.OleDb.OleDbException in Progress.o4glrt). You will continue to generate your strongly-typed proxies the standard way (with Proxygen against the .Net framework). But you should be able to reference these assemblies from a .Net standard class library. And at runtime everything should work too (on .Net core). As Matt said, any problems you encounter in this configuration will not be fully supported by Progress. In order to get support you will probably need to recreate your problems in a .Net Framework client application first. As far as I know, Progress has not started to formally support either the .Net core or .Net standard.
Continue reading...
Continue reading...