Upgrade .NET version support for AF SDK
Please add support for .NET Core to the AF SDK. Currently only full .NET Framework is supported.
Thank you all for your valuable feedback. While we appreciate the interest the community has for this suggestion, we have decided to not pursue this item for now in favor of other high priority work. We realize that this is a popular idea, and we will continue to evaluate its impact for our customers and partners. We will update this idea’s status if we begin to work on this.
For non-Windows environments, our current suggestion is to use the PI Web API for programmatic PI Server access.
It's sad to see so much legacy work being tossed aside, sacrificed to the altar of "do it on the web". It is miles away from OSIsoft's original ethos which was to facilitate communication rather than prescribe how it should be done. For Microsoft systems WebAPI is a tedious substitute.
.NET 6 has been officially released and is an LTS release.
To echo previous commenters, the urgency with this request was NOT regarding cross platform opportunities (though those would be a huge plus!), but rather compatibility with any of the primary components in the .NET ecosystem (e.g. ASP.NET Core).
Starting a project in any of the ecosystem tools (Visual Studio, dotnet SDK, etc) today defaults to .NET5/6/standard2.0/standard2.1. It has become increasingly difficult to use AFSDK in projects as more and more libraries are dropping support for .NET Framework 4.x.
Running a Portability Analysis in Visual Studio (https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer) on AFSDK indicated a very small fraction of the library as incompatible with .NET5 with Platform Extensions (which merely would require consumers to include some additional nuget packages). It seems that it wouldn't require much to migrate to netstandard/net5/6 APIs.
At the very least have you considered isolating the incompatible parts of AFSDK and offering a subset that is compatible?
Please. Just look at the main landing page for .NET docs today to get an idea of where the ecosystem is at:
This is not a 'popular idea' where 'community interest' or 'use cases' should be a deciding factor. This is the current/status quo. With LTS release of .NET 6 there really isn't a fair argument as to why this isn't at least under development.
P.S. also echoing other commenters....Web API is NOT an acceptable substitute.
So this request isn't typically just about cross platform development. As has already been mentioned by others, there is no true equivalence between PI Web API and AF SDK, in both performance and functionality.
For me the key drivers behind support for later versions of .Net are to be able to take advantage of new features and performance improvements since .Net Framework 4.8. Whilst end of life support appears to be a long way off for .Net 4.8, it will come and it would be nice to know that OSIsoft is keeping their technology both up to date and relevant.
Seems that just about the entire stack is going stale, and that all focus is on OCS. There's a fairly large ecosystem of users & partners that are dependent upon the 'legacy' parts of OSISoft's technology stack, and it is very much starting to feel like they are being left behind without any real explanation of why OSIsoft seems to no longer care about the vast amount of on-prem servers and related products and third-party solutions.
Sad to hear the decision to delay this improvement.
PI Web API and AFSDK are not equivalent, by far. Features are still missing in the former, especially to manage AF/AA (cannot backfill, etc.). Performance and development cost is also an issue when it comes to operate large AF element trees and their attributes because querying throw API requires fine tuning (batching, paging, rate limit, error managing) which is not as simple 'out of the box' as AFSDK requesting.
I don't understand how OSISOFT PI, a software that the only mission is to communicate with other softwares and register its data, doesn't support .NET any more.
I hope new owners of AVEVA have fired the whole team responsibles of taking this so bad decision.
And two fresh problems.
Several libraries now requires .NET 5.0 in order to work properly with Azure AD.
And, today I could really really benefit from System.IO.Pipelines, but then I can't because someone has decided to die on the hill of .NET Framework 🪦 and we're stuck with whatever is supported in .NET Standard 2.0
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.