Opera 3 SQL SE development - DIT/SE libraries target .NET Framework

Given that Infor failed to migrate the old Developer Forum to this new platform, despite me asking them to do so, I am raising this issue here, and it relates to Opera 3 SQL SE developers only.

The Pegasus Opers SQL SE DIT/EAT libraries (e.g. OperaIMS.dll, OperaCommands.dll, OperaClientDLL.dll etc.) have been developed to target .NET Framework 4.7.2.

This means that my SE development (DLLs), using the DIT, and the EAT, to access the Opera SE SQL Server databases, has been written using C#, targetting .NET Framework 4.7.2.

My customer, has been writing a website that will consume my DLLs but, as with any current .NET developer worth their salt, has developed using .NET targetting .NET Core 8. This is hardly surprising given that .NET Core has been available since 2016.

The issue, of course is that my .NET Framework DLLs are not compatible with my customer's .NET Core website.

An attempt to write a wrapper around my DLLs has also failed becuase Opera SE uses the Net.Tcp Port Sharing Service and, buried deep in the OperaIMS library, is a call to the set_PortSharingEnabled() method.

This method has been deprecated, by Microsoft, in later versions of .NET Core, and so attempts to call my DLL to connect to the Opera 3 server, crashed with error "Method not found: 'Void System.ServiceModel.NetTcpBinding.set_PortSharingEnabled(Boolean)'"

I'm currently at a grinding halt, with regards to this project, meaning man-months of wasted work, not to mention the commercial committments for the project.

Have any other Opera 3 SE developers encountered this issue and, more importantly, found a resolution?

I'm guessing not, otherwise I woud have hoped that pressure would have already been placed on Pegasus to provide a version of the DIT/EAT libraries that target .NET Core.

I have, of course, escalated this issue with Pegasus, via various avenues, and they are currently looking into it not that, with all due respect, there is likely to be a quick resolution.

Any thoughts would be much appreciated

Steve

Find more posts tagged with

Comments

alan-bourke

Hi Steve

What will the website be consuming from Opera SE? Is it read only, or writing back also?

If it's only reading data from SE then the DataConnector might be an easier option?

If it's writing back also then it might be a case of having to put another layer in between.

For example a Windows service built in NET Framework 4.8 referencing your EAT DLLs. And providing an API so that the .NET Core website can talk to it and pull\push JSON data.

Or .NET Framework Compatibility Mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode (no experience of this personally)

But yes, palaver.

Steve Loader

Thanks for your quick response, Alan, much appreciated.

What I have written is a series of APIs that allow access to the Opera 3 SQL SE databases, via the Pegasus recommended EAT channel, ensuring appropriate Opera 3 SQL SE security is maintained.

I did initially consider using the Data Connector but, unfortuantely, there is at least one write-back API (to post an SOP Invoice), and there may be more in the future.

I do have an intermediate layer, in order to simplify the complexity of the EAT methods, and provide simple API methods with the minimum number of parameters. However, the intermediate layer references the API DLL (which targets .NET Framework 4.7.2, because it has to reference the Pegasus libraries), and so also has to target .NET Framework 4.7.2.

The .NET Core website then has to reference the APIs in my intermediate layer, which it can't do because the intermediate layer itself targets .NET Framework 4.7.2.

Does that make sense, or have I missed the point?

I am currently considering whether to re-write (as much of a pain as it will be) the read-only APIs to use the Data Connector, and the write-back APIs to access the SQL Server databases direct in lieu, of course, of Pegasus providing .NET Core compliant libraries.

I'm completely deflated at present, but need to agree on a viable solution, and get my finger out 🤣

Thanks again

Steve

alan-bourke

What I was getting at is, if you provide say A REST API developed in .NET 4.8, it can obviously reference your EAT solution assemblies. It would also be able to accept requests and data in JSON format from the .NET 8 website, over HTTP. So that provides a layer of isolation and it doesn't matter to the .NET 8 website what the backend is.

Alternatively, assuming all this is on the same network, when an invoice needs to be created you could just get the website developer to put a file with the invoice details in a known location (in CSV, JSON, XML format etc) and then you could scan that location periodically and process any new files.

Steve Loader

Thanks for your quick response, Alan, much appreciated.

What I have written is a series of APIs that allow access to the Opera 3 SQL SE databases, via the Pegasus recommended EAT channel, ensuring appropriate Opera 3 SQL SE security is maintained.

The .NET Core website then has to reference the APIs in my intermediate layer, which it can't do because the intermediate layer itself targets .NET Framework 4.7.2.

Does that make sense, or have I missed the point?

Steve

Copyright © 2025 Infor. All rights reserved.