- 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.

1. .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