This package is a logical extension of .NET Standard 2.0 that significantly increases API set and existing code compiles with almost no modifications. But in order to keep the promise of .NET Standard ("it is the set of APIs that all .NET implementations provide"), this didn't include technologies that can't work across all platforms, such as registry, Windows Management Instrumentation (WMI), or reflection emit APIs.
The Windows Compatibility Pack sits on top of .NET Standard and provides access to technologies that are Windows only. It's especially useful for customers that want to move to .NET Core but plan to stay on Windows as a first step. In that scenario, not being able to use Windows-only technologies is only a migration hurdle with zero architectural benefits.
Regarding this question:
Why hasn't Microsoft started build some kind of cross platform abstraction api for common tasks?
You mean like a set of APIs that cover basic tasks like reading files, accessing the network, or parsing documents? Yeah, that's what .NET Standard is (a)
Seriously, what APIs would like to see being abstracted?
@TerraJobst Great! A big concern about PoShCore is compatibility with scripts, DSC resource modules, and DSC configurations written for Windows PoSh 5.1, but this Compatibility Pack might be very important for reducing these fears. Can you share any testing or plans in this regard? Thanks!
The PowerShell team would be better suited to answer these questions. I suggest you ask here.
I don't fully understand what "Microsoft.NETCore.Portable.Compatibility" and "NETStandard.Library" are.
Microsoft.NETCore.Portable.Compatibility is a NuGet package that provides the magic that makes your project compatible with existing Portable Class Libraries (PCL). PCLs were our solution to create class libraries that can be shared across multiple .NET flavors, prior to .NET Standard.
NETStandard.Library that's the NuGet package that you reference to build a class library targeting .NET Standard 1.x.
@dcuccia:Sorry for the delay. I was confused which two of the three questions I should answer (6)
1. Yes, we're playing around with the idea of provide an analyzer.
2. That's an interesting suggestion.
3. Are you asking whether our suggestion engine could be extended to incorporate non-platform libraries? We've talked about this recently and came to the conclusion that it should be possible as our engine used string-based IDs to refer to APIs.
These are all excellent ideas. I suggest you file issues on GitHub so we can talk about them there in more detail!