.NET Standard - NuGet Analysis
Download as PPTX, PDF2 likes1,084 views
- The document analyzes .NET API and P/Invoke compatibility of NuGet packages. It finds that 63% of top 1000 packages and 69% of all packages are compatible with .NET Standard 2.0. - Of incompatible packages, many depend on app models like ASP.NET or use over 50 missing APIs. Excluding these, most packages only use a small number of missing APIs. - A small percentage of compatible packages use P/Invokes, mostly depending on Windows APIs, but many use only a few APIs.
.NET Standard - NuGet Analysis
- 2. Context Part 1 .NET API Compatibility Part 2 P/Invoke Compatibility
- 3. Part 1: .NET API Compatibility • We’ve looked at packages and checked which .NET APIs they are using • Top 1000 • All • We’ve broken down the packages into three buckets: • Packages that target .NET Standard/PCLs • Packages that only use APIs available in .NET Standard 2.0 • Packages that use APIs unavailable in .NET Standard 2.0 • We’ve grouped the missing APIs by namespace and plotted how strong a package depends on it
- 4. Compatibility of the Top 1000 Packages 63 % are API compatible with .NET Core & Standard 2.0 Still Incompatible 37 %30 % 33 %Top 1000 Provide portable asset Only use available APIs Use unavailable APIs 24 % Uses app-model specific APIs, such as • Classic ASP.NET • WinForms • WPF • Xamarin Android & iOS From those 87 % have also .NET Framework assets of which 70 % are compatible with .NET Core & Standard
- 5. 0 20 40 60 80 100 120 140 160 180 200 (ASP.NET Classic) (WinForms) (WPF) (Xamarin Android) Microsoft.Win32 System System.Collections System.ComponentModel System.ComponentModel.Composition System.Data System.Diagnostics System.Drawing System.IdentityModel System.Net System.Reflection System.Runtime System.Security System.ServiceModel <= 1 <= 5 <= 10 <= 20 <= 50 More Top 1000: Incompatible API Usage # of missing APIs per package Take Away Most packages depend on classic ASP.NET Packages depending on app models often use 50+ APIs
- 6. 0 10 20 30 40 50 60 System System.Runtime System.Security System.Reflection System.Data System.Diagnostics System.Drawing System.ComponentModel.Composition System.Net Microsoft.Win32 <= 1 <= 5 <= 10 <= 20 <= 50 More Top 1000: Incompatible API Usage Excluding “lost causes”, i.e. only packages with no app model dependencies Take Away Small # app-model agnostic (120) Looking at remaining technologies there seem to be plenty of packages that only use <= 5 APIs # of missing APIs per package
- 7. Compatibility of all packages on NuGet 69 % are API compatible with .NET Core & Standard 2.0 Still Incompatible 32 %12 % 56 %All Packages Provide portable asset Only use available APIs Use unavailable APIs 37 %30 % 33 %Top 1000 20 % Uses app-model specific APIs, such as • Classic ASP.NET • WinForms • WPF • Xamarin Android & iOS From those 50 % have also .NET Framework assets of which 88 % are compatible with .NET Core & Standard
- 8. 0 1000 2000 3000 4000 5000 6000 7000 8000 (ASP.NET Classic) (WinForms) (WPF) (Xamarin Android) (Xamarin iOS) Microsoft.VisualBasic Microsoft.Win32 System System.Collections System.ComponentModel System.ComponentModel.Composition System.Data System.Diagnostics System.Drawing System.Management System.Net System.Reflection System.Runtime System.Security System.ServiceModel <= 1 <= 5 <= 10 <= 20 <= 50 More All Packages: Incompatible API Usage Take Away Most packages depend on classic ASP.NET Packages depending on app models often use 50+ APIs # of missing APIs per package
- 9. 0 200 400 600 800 1000 1200 1400 1600 Microsoft.Build Microsoft.VisualBasic Microsoft.Win32 System System.Collections System.ComponentModel System.ComponentModel.Composition System.Configuration System.Data System.Diagnostics System.Drawing System.IO System.Management System.Messaging System.Net System.Reactive System.Reflection System.Runtime System.Security System.ServiceModel <= 1 <= 5 <= 10 <= 20 <= 50 More All Packages: Incompatible API Usage Excluding “lost causes”, i.e. only packages with no app model dependencies # of missing APIs per package Take Away Relatively small # app-model agnostic (7000) Looking at remaining technologies there seem to be plenty of packages that only use <= 5 APIs
- 10. Conclusion Part 1: .NET API Compatibility • 69 % of all available NuGet packages are API compatible with .NET Standard/.NET Core 2.0 • We shouldn’t prefer .NET Framework assets when compatible assets exists because in those cases only 70 % are compatible with .NET Standard/Core 2.0 • Where both assets exist, in top 50 non-MSFT packages, the Standard asset uses ~10% fewer API (outliers: in one case 50% less): ie potentially cut-down functionality • 20 % of all NuGet packages are app-model specific and thus not applicable • Most depend on classic ASP.NET • Packages depending on app models often use 50+ APIs • 11 % of all NuGet packages use missing APIs • The most used component we don’t have is System.Drawing • Missing APIs in System.Data are in the process of being addressed • The rest is distributed across a wide variety of technologies that we already support in .NET Standard • Fixing missing APIs in existing tech is hard as they are already maxed out
- 11. Part 2: P/Invoke Compatibility • We’ve looked at packages and checked which P/Invokes are being declared • Top 1000 • All • We’ve broken that down into the same categories as for managed APIs • We’ve bucketized the P/Invokes (e.g. Windows, libc etc) and plotted how strong a package depends on it
- 12. P/Invokes in the Top 1000 Packages 37 %30 % 33 %Top 1000 Provide portable asset Only use available APIs Use unavailable APIs P/Invokes 3 % 4 % 5 % 11 % of the API compatible packages have P/Invokes
- 13. P/Invokes in all packages on NuGet 32 %12 % 56 %All Packages Provide portable asset Only use available APIs Use unavailable APIs P/Invokes 0.4 % 4 % 4 % 6.5 % of the API compatible packages have P/Invokes
- 14. 0 10 20 30 40 50 60 70 (ikvm) (sqlite3) (Windows) /usr/lib/libobjc.dylib /usr/lib/libsystem.dylib credui dnsapi libc libdl mpr powrprof winmm <= 1 <= 5 <= 10 <= 20 <= 50 More Top 1000: P/Invokes in compatible libraries Take Away Most packages with P/Invokes depend on Win32 A decent amount of them only use a few APIs Excluding “lost causes”, i.e. only packages with no app model dependencies
- 15. 0 500 1000 1500 2000 2500 (sqlite3) (Windows) /usr/lib/libobjc.dylib credui Cryptdll esent iprop libc mpr mtxex ntdsapi rpcrt4 security Syncfusion.WebKitWrapper version winmm <= 1 <= 5 <= 10 <= 20 <= 50 More All Packages: P/Invokes in compatible libraries Take Away Most packages with P/Invokes depend on Win32 A decent amount of them only use a few APIs Excluding “lost causes”, i.e. only packages with no app model dependencies
- 16. Conclusion Part 2: P/Invoke Compatibility • Less than 7% of the packages that are API compatible have P/Invokes • Most heavily depend on Win32 • Those libraries should work fine on Windows but won’t work as well on Linux • The P/Invoke analysis does not change the earlier conclusion