Page 64 - MSDN Magazine, December 15, 2017

.NET
Introducing the
Windows Compatibility
Pack for .NET Core
Immo Landwerth
The Microsoft .NET Framework is still the best choice for certain styles of apps, especially for desktop apps and Web apps that use ASP.NET Web Forms. But if you need highly scalable Web apps, create self-contained deployments using Docker, or if you need to run on Linux, then you want to consider porting to .NET Core. But bringing existing code to .NET Core can be a challenge. In this article, I’ll explain how you can use the new Windows Compatibility Pack for .NET Core. It provides access to APIs that were previously available only for .NET Framework (for example, System.Drawing, System.DirectoryServices, ODBC, WMI and many more). Because this includes both cross-platform and Windows-only technologies, it’s critical to understand early if you’re using APIs that might interfere with your cross-platform goals. I’ll address this by showcasing the new API analyzer, which gives you live feedback as you’re editing code.
Overview
When we shipped .NET Core 1.x, as well as .NET Standard 1.x, we were hoping to be able to use this as an opportunity to remove leg- acy technologies and deprecated APIs. Since then, we’ve learned
that no matter how attractive the new APIs and capabilities of .NET Core are, if the existing code base is large enough, the benefits of the new APIs are often dwarfed by the sheer cost of reimplementing or adapting that code. Luckily, the Windows Compatibility Pack pro- vides a good chunk of these technologies so that building .NET Core applications and .NET Standard libraries becomes much more viable for existing code.
This capability is a continuation of .NET Standard 2.0 (bit.ly/ 2iuekmN), in which we significantly increased the number of APIs that can be shared across all .NET implementations, especially .NET Core. The goal was to make porting existing code much easier and ensure it largely compiles just as is. However, we also didn’t want to complicate .NET Standard by adding large APIs that can’t work across all platforms, which is why we haven’t added the Windows registry or reflection-emit APIs. Because the Windows Compatibility Pack is a separate NuGet package and sits above .NET Standard, it’s free to provide access to technologies that are Windows-only.
Providing more APIs for class libraries that target .NET Standard also helps with the compatibility mode we’ve added in .NET Stan- dard 2.0. This compatibility mode allows the referencing of existing .NET Framework binaries, which helps with the transition period where many packages aren’t yet available for .NET Standard or .NET Core. But this compatibility mode doesn’t change physics: It can only bridge differences in assembly names between .NET Framework and .NET Standard. It can’t give you access to APIs that don’t exist for the .NET implementation on which you’re running. For example, if you’re referencing a .NET Framework library that uses System.Directory- Services, it will fail if you run it on .NET Core 2.0 today, because System.DirectoryServices isn’t included in .NET Core. The Windows Compatibility Pack helps to extend the set of APIs covered by the compatibility mode by bringing in System.DirectoryServices.
This article discusses:
• Migrating to .NET Core
• Using helpful tools: API Port, Windows Compatibility Pack, API
Analyzer
• Understanding Windows-only dependencies Technologies discussed:
.NET Core, .NET Standard, API Port, Windows Compatibility Pack, API Analyzer
60 msdn magazine