Microsoft has announced the Windows Compatibility Pack for .NET Core. The company says the pack simplifies the process of porting existing code to the open source web framework. Created for developers, the compatibility pack features access to a further 20,000 APIs from a NuGet package.
In a blog post, Microsoft says porting existing code to .NET Core was a challenging task that was made easier through the release of .NET Core 2.0. However, customers wanted the process to be even easier.
The Windows Compatibility Pack makes the porting simple. Microsoft says developers still need to understand when to use DOTNET Core or .NET Framework:
“.NET Core is optimized for building highly scalable web applications, running on Windows, macOS or Linux. If you’re building Windows desktop applications, then the .NET Framework is the best choice for you.”
Customers are advised to download Windows Compatibility Pack before moving .NET Framework to a .NET Core project. Microsoft wants customers to have as many APIs as possible, so is also recommending the NuGet package.
The compatibility pack is current in preview. The number of APIs available in limited, with more to come through future builds. Microsoft has provided a table (above) to show which APIs are available in preview, and which are coming soon.
Windows-Only API Management
Around half of the API components in the pack are restricted to Windows only. However, the rest will work across platforms. Microsoft understands that knowing which components are Windows only is time consuming. Users could go to the inconvenience of checking the documentation. However, the company has instead launched the API Analyzer tool.
Announced earlier this month, the API Analyzer is basked on Roslyn and denotes Windows-only APIs. Microsoft points to the following three options for managing Windows-only APIS:
- “Remove. Sometimes you might get away with simply deleting the code as you don’t plan to migrate certain features to the .NET Core-based version of your application.
- Replace. Usually, you’ll want to preserve the general feature so you might have to replace the technology with one that is cross-platform. For example, instead of saving configuration state in the registry, you’d use text-based configuration files you can read from all platforms.
- Guard. In some cases, you may want to call the Windows-only API when you’re running on Windows and simply do nothing (or call a Linux-specific API) when you’re running on Linux.”