Upgrade .NET version support for AF SDK
Please add support for .NET Core to the AF SDK. Currently only full .NET Framework is supported.
With the introduction of CoreWCF 1.0, we are re-evaluating this request. Performance, backwards compatibility, security, and technological longevity are key features that we are researching.
Please continue to share your use cases with us, as well as any key capabilities that your use case requires.
Cross development. The ability to build Edge applications that run in containers on IIOT gateways, acting as a data broker/forwarder would be just amazing. AFSDK is, as far as we're concerned, one of the huge differentiators between PI Server vs. other historian products out there. We love it.
Asle Frantzen commented
I'm joining the choir here, and hoping this will be prioritized by OSIsoft/AVEVA. We create a fair amount of backend services interacting with the AF SDK, and feel stuck/left behind when it comes to the .NET Framework dependency today.
PI WebAPI is not a good substitution for the AF SDK!
It is pretty much required to upgrade AF SDK to support .NET 6+. Also the dependency has to be converted to proper Nuget packages.
This is long time due, and holding it because of lack of WCF was not the right move to start with. Microsoft is clear that WCF is now a relic of the past. CoreWCF is a community project with Microsoft backing and it has taken a long time to reach a 1.0 release.
As others have mentioned, PI Web API is not equivalent.
We have a project that was successfully migrated to .NET Core, including even OPC Components. Only PI SDK is still stuck at .NET Framework which is adding unnecessary overhead.
This is wonderful news. Our infrastructure is Linux based and we continue to use the deprecated Linux SDK. We want to invest in a new client, but this requires adding Windows infrastructure and training or hiring a Windows developer.
It would be wonderful if we could continue to use our existing infrastructure, tools and expertise.
John Messinger commented
Would very much like to see serious reconsideration of this decision in light of Microsoft's latest announcement regarding CoreWCF 1.0. Given the key reason for not supporting .NET 5 and later was lack of support for WCF, seems that this technical blocker no longer exists.
As mentioned before, PI Web API is not a suitable replacement for the AF SDK.
The biggest technical obstacle to migrating AF SDK to .NET 6 was the lack of WCF in .NET 6. On Thursday, April 28, 2022, Microsoft announced CoreWCF 1.0 was released into production with Microsoft Product Support available.
Given this major news, will OSIsoft be reconsidering their Oct 13, 2021 decision?
Very disappointed with the Admins response and suggestion for PI Web API as a workaround. I mimic a lot of other posters comments here about the need to keep up with versions of .net and that cross platform isn't necessarily the issue. Maybe OSIsoft needs to make the library open source if you're not going to maintain it yourself?
Please reconsider this requirement. We are forced to overcomplicate our systems' architectures just because of the limited support from a core component of the PI System.
Big oof. Please do this! Or at least give us a roadmap target! Please? Pretty please?
Any new updates?
We need .NET 5 support.
This cannot be ignored!
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.
John Messinger commented
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