Upgrade .NET version support for AF SDK
Please add support for .NET Core to the AF SDK. Currently only full .NET Framework is supported.
We are evaluating this idea and would like to hear more about your use cases.
Use case: Lambda functions in AWS for data migration and calculation operations
I'd like to leverage emerging capabilites of Entity Framework Core 6 such as support for Noda Time and SQL Temporal to work along side AF SDK which would require the SDK to work on .NET 6
Jeff Parker commented
Here are some use cases:
- Stand alone library, no system install or prerequisite installs (dotnetstandard2.1 or net5.0/net6.0)
- No intermediary web-service/webapi between AF/PI and client
- Support for windows and linux
- Create and modify AF templates
- Create and modify AF elements, including bulk methods
- Create and modify PI tags, including bulk methods
- Query AF Data, search for elements based on hierarchy or template
- Query AF real time data
- Sort AF search results base on attribute values (e.g. top 10 values of X element attribute)
- Query AF historical attribute data
- Retrieve subset of AF attribute values belonging to an element
- Query PI Tag metadata
- Query PI tag historical data
- Stream PI tag data in real time
- Stream AF data in real time
- Query event frame historical data
- Sign up for notifications of Event Frames
For us the use cases would be mostly related to the development of serverless applications. The WEB API does not provide the same performance level and some advanced features appear to be missing with respect to the AFSDK.
The main use case will be of course to be able to run/migrate code developed using PI AF SDK under .NET 4.x to .NET Core and .NET 5+.
We have a solution that was fully migrated to .NET Core (even OPC Core Components are possible to migrate). However, only PI AF SDK is lagging behind and we are not able to directly migrate.
Another use case is using AF SDK from Azure Functions. The SDK needs to be converted to Nuget package in order to be able to do so.
PI to PI implementation over Unidirectional Gateway.
- full tags replication from source to destination PI server
- tags replication based on search criteria (same as tags search at SMT)
- Automatically tags creation, deletion and modification
- Connecting to single PI Server or Collective
- close to real time tags values update replication
- Re transmit Archive values
- And more..
All this based on the PI AF SDK. I'm looking for a solution to run all this capabilities on a Linux OS rather than Windows. I'm trying to prevent using the OLD PI C API for that purpose.
One day, I Have developed a little console application under .net core.
At the end of the project, I only realize that PI af sdk was not supported on this target framework.
as workaround, I have created a new project based on .Net framework.
It might be good for customers if one day osisoft could add .net core support for af sdk.
I have a complete use case that involve the migration of an existing MVC5 Asset Management Frontend which completely rely on AF SDK. You can contact me for further details
Use Case: Create streaming integrations with Azure/AWS for real time event driven functionality
Use Case: Standalone packaging like NuGet for portability and interoperability
Use Case: Horizontal and Vertical scaling using cloud resources
Use Case: Modern security scanning/tooling compatibility
Use Case: Modernize to get the auditors off my back!!!
At Owl Cyber Defense, we sell security hardened systems to securely transfer information between networks. Many of our customers use PI, and one of our older offerings uses PI API and PI SDK to essentially replicate a PI Server from one network to another. We've leveraged PI Web API for a newer solution but it isn't capable, or meant for, the types of loads we're working with. Updating/replacing our older solution (Linux based) to use AFSDK would be the ideal path forward.
@KevinGeneva, you've got my contact info, reach out if you want to know more.
Use Cases I can see:
- programs can be run on Linux, for platform interoperability
- programs can be run in AWS Lambda, assisting modern architecture designs
- programs can be run as .NET core instead of .NET 4.x.x, getting to modern language
- dependency injection, for better unit testing
@Kevin, can we rename this from asking for .NET Core to .NET 5? Framework and Core are in the past, I don't see how OSI can not support .NET 5 if you want to stay relevant.
Any update on this topic? .net core 6 is bringing full unification ... https://auth0.com/blog/dotnet-5-whats-new/
Any update? We'd love to have AFSDK in a current language.
Asle Frantzen commented
Any updates to this? It will be a pain if we can't communicate with AF through the SDK in our modern .NET applications.
Any updates? I am getting the question about .NET 5/ .NET Core support for the AF SDK from my colleagues more and more. What can I tell them?
Steve Boyko commented
Is there any update on .NET 5 / .NET Core support for AF SDK? This has been repeatedly asked in PI Square for at least the past 3 years.
See also the request for Linux support at https://feedback.osisoft.com/forums/555145-pi-developer-technologies/suggestions/35508820-af-sdk-and-web-api-on-linux-os-es#comments
Harald Ulriksen commented
So this has been frequently requested since at least 2016. And with the release of .NET 5 it is clear that WCF is not a priority. Meanwhile there has been a massive work on performance on .NET with Span<T>, Pipelines, Kestrel you name it. WCF is NOT even mentiond while Microsoft actively work on GRPC performance and are now at the very top of several Techempower benchmarks.
There are many reasons to support this, ranging from Linux support, performance, security, to just keeping up with the development in the overall .NET ecosystem. It makes it very hard to get OSISoft to play with the other code one is building.
What do we do if there's a security liability in another 3rd party package which requires us to upgrade to .NET Core because they just don't maintain .NET Framework any more? One can't.
The lack of .NET Cor/.NET 5 is quickly becoming a problem. And quite frankly what seems like lack of interest from OSISoft comes across as lack of interest and disregard for the developer story.
Kenneth Barber commented
The title should be changed to say ".NET 5" instead of ".NET Core". .NET 5 was released a few days ago.