.NET Core 2 is a great release from many angles. By implementing .NET Standard 2.0, it doubles a number of API which can be shared between .NET Core and .NET Standard applications. It allows reference of .NET Framework libraries. In some aspects it even faster than .NET Framework. But is it enough to allow migration of the real-world .NET Framework code to .NET Core?

Results of running compatibility analyzer on an enterprise-grade code base will be unspectacular. These types of applications heavily use XML configuration and ConfigurationSection which are not part of .NET Standard, they often depend on WCF and they use WinForms or WPF for UIs. From my experience, even for UI-less libraries, about 20% of code is not transferrable between .NET Core and .NET Standard.

Windows Compatibility Pack for .NET Core aims to fill this gap.

Compatibility pack is a set of packages which provide the missing APIs and allow to share more code between the platforms. UI libraries are still missing, but back-end developers should be happier now.

Compatibility pack solves the problem of missing APIs by combining type-forwarding and re-implementation approaches.

When an API exposed by the compatibility pack is used in .NET Framework execution environment, the type is forwarded and an existing .NET Framework implementation is used. However, for .NET Core, the pack provides new implementation.

It is important to understand, that Windows Compatibility Pack does not bring all these new features to other platforms. It allows to use missing APIs, but some of them are only for Windows platform, because even re-implemented code still depends on Windows.

Windows Compatibility Pack for .NET Core is not a permanent solution which will stay in codebase forever. Intention of the pack is to build a temporary bridge, allowing adoption of .NET Core to a greater extend. However, in the long term the goal stays the same – replace outdated APIs and features of .NET with newer .NET Standard-compatible alternatives.