Who is this package for?

This package is meant for developers that need to port existing .NET Framework code to .NET Core. But before you start porting, you should understand what you want to accomplish with the migration. Just porting to .NET Core because it’s a new .NET implementation isn’t a good enough reason (unless you’re a True Fan).

.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. Take a look at our documentation for more details on how to choose between .NET Core and .NET Framework.

Demo

For a demo, take a look at this video:

Using the Windows Compatibility Pack

We highly recommend that you plan your migrations as a series of steps instead of assuming you can port the existing code base all at once. If you’re planning to migrate an ASP.NET MVC application running on a local Windows server to an ASP.NET Core application running on Linux in Azure, we’d recommend you perform these steps:

  1. Migrate to ASP.NET Core (while still targeting the .NET Framework)
  2. Migrate to .NET Core (while staying on Windows)
  3. Migrate to Linux
  4. Migrate to Azure

The order of steps might vary, depending on your business goals and what value you need to accomplish first. For example, you might need to deploy to Azure before you perform the other migration steps. The primary point is that you perform one step at a time to ensure your application stays operational along the way. This reduces the complexity and churn you have to reason about at once. It also allows you to learn more about your code base and adjust your plans as you discover issues.

The Porting to .NET Core from .NET Framework documentation provides more details on the recommended process and which tools you can use.

Before bringing existing .NET Framework code to a .NET Core project, we recommend you first add the Windows Compatibility Pack by installing the NuGet package Microsoft.Windows.Compatibility. This maximizes the number of APIs you have at your disposal.

The Windows Compatibility Pack is currently in preview because it’s still a work in progress. The following table describes the APIs that are already part of the Windows Compatibility Pack or are coming in a subsequent updat

Component Status Windows-Only Component Status Windows-Only
Microsoft.Win32.Registry Available Yes System.Management Coming Yes
Microsoft.Win32.Registry.AccessControl Available Yes System.Runtime.Caching Coming  
System.CodeDom Available   System.Security.AccessControl Available Yes
System.ComponentModel.Composition Coming   System.Security.Cryptography.Cng Available Yes
System.Configuration.ConfigurationManager Available   System.Security.Cryptography.Pkcs Available Yes
System.Data.DatasetExtensions Coming   System.Security.Cryptography.ProtectedData Available Yes
System.Data.Odbc Coming   System.Security.Cryptography.Xml Available Yes
System.Data.SqlClient Available   System.Security.Permissions Available  
System.Diagnostics.EventLog Coming Yes System.Security.Principal.Windows Available Yes
System.Diagnostics.PerformanceCounter Coming Yes System.ServiceModel.Duplex Available  
System.DirectoryServices Coming Yes System.ServiceModel.Http Available  
System.DirectoryServices.AccountManagement Coming Yes System.ServiceModel.NetTcp Available  
System.DirectoryServices.Protocols Coming   System.ServiceModel.Primitives Available  
System.Drawing Coming   System.ServiceModel.Security Available  
System.Drawing.Common Available   System.ServiceModel.Syndication Coming  
System.IO.FileSystem.AccessControl Available Yes System.ServiceProcess.ServiceBase Coming Yes
System.IO.Packaging Available   System.ServiceProcess.ServiceController Available Yes
System.IO.Pipes.AccessControl Available Yes System.Text.Encoding.CodePages Available Yes
System.IO.Ports Available Yes System.Threading.AccessControl Available Yes

Handling Windows-only APIs

If you plan to run your .NET Core application on Windows only, then you don’t have to worry about whether an API is cross-platform or not. However, if you plan to migrate your application to Linux or macOS, you need to take the platform support into account.

As you can see in the previous table, about half of the components in the Windows Compatibility Pack are Windows-only, the other half works on any platform. Your code can always assume that all the APIs exist across all platforms, but if they are Windows-only they throw PlatformNotSupportedException. This allows you to write code that calls Windows-only APIs after doing a platform check at runtime, rather than having to use conditional compilation using #if. We recommend you to use RuntimeInformation.IsOSPlatform() for platform checks:

private static string GetLoggingPath()
{
// Verify the code is running on Windows.
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
{
if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
return configuredPath;
}
} // This is either not running on Windows or no logging path was configured,
// so just use the path for non-roaming user-specific data files.
var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging");
}

You might wonder how you’re supposed to know which APIs are Windows-only. The obvious answer would be documentation, but that’s not very convenient. This is one of the reasons why we introduced the API Analyzer tool two weeks ago. It’s a Roslyn-based analyzer that will flag usages of Windows-only APIs when you’re targeting .NET Core and .NET Standard. For the previous sample, this looks as follows:

You have three options to deal with Windows-only API usages:

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

In the previous example, the code is already written in such a way that it provides a default configuration when the setting isn’t found in the registry. So the easiest solution is to guard the call to registry APIs behind a platform check.

The Windows Compatibility Pack is designed as a metapackage, meaning it doesn’t directly contain any libraries but references other packages. This allows you to quickly bring in all the technologies without having to hunt down various packages. But as your port progresses, you may find it useful to reference individual packages instead. This allows you to remove dependencies and ensure newly written code in that project doesn’t take a dependency on it again.

Summary

When you port existing code from the .NET Framework to .NET Core, install the new Windows Compatibility Pack. It provides access to an additional 20,000 APIs, compared to what is available in .NET Core. This includes drawing, EventLog, WMI, Performance Counters, and Windows Services.

If you plan to make your code cross-platform, use the new API Analyzer to ensure you don’t accidentally depend on Windows-only APIs.

But remember that the .NET Framework is still the best choice for building desktop applications as well as Web Form-based web applications. If you’re happy on the .NET Framework, there is also no reason to port to .NET Core.

Let us know what you think!

.net core compatibility windows & windows compatible Linux的更多相关文章

  1. Running ASP.NET Core applications on Windows Subsystem for Linux

    Setting up Linux on Windows 10 First thing is to enable Windows Subsystem for Linux. It doesn’t inst ...

  2. NET Core应用可以同时运行在Windows Container和Linux Container-1

    NET Core多平台开发体验[1]: Windows 微软在千禧年推出 .NET战略,并在两年后推出第一个版本的.NET Framework和IDE(Visual Studio.NET 2002,后 ...

  3. .NET CORE QuartzJob定时任务+Windows/Linux部署

    前言 以前总结过一篇基于Quartz+Topshelf+.netcore实现定时任务Windows服务 https://www.cnblogs.com/gt1987/p/11806053.html.回 ...

  4. 如何实现在Windows上运行Linux程序,附示例代码

    微软在去年发布了Bash On Windows, 这项技术允许在Windows上运行Linux程序, 我相信已经有很多文章解释过Bash On Windows的原理, 而今天的这篇文章将会讲解如何自己 ...

  5. WSL(Windows Subsystem for Linux)--Pico Process Overview

    [转载] Windows Subsystem for Linux -- Pico Process Overview Overview This post discusses pico processe ...

  6. Windows远程连接Linux

    目录 xrdp方式 vnc方式 xrdp方式 ----------------------------------------------------------------------------- ...

  7. 使用NSSM把.Net Core部署至 Windows 服务

    为什么部署至Windows Services 在很多情况下,很少会把.Net Core项目部署至Windows服务中,特别是Asp.net Core就更少了.一般情况下,Asp.net Core会部署 ...

  8. NSSM把.Net Core部署至 Windows 服务

    NSSM把.Net Core部署至 Windows 服务 https://www.cnblogs.com/emrys5/p/nssm-netcore.html 为什么部署至Windows Servic ...

  9. Windows软件在Linux上的等价/替代/模仿软件列表 (抄一个)

    Last update: 16.07.2003, 31.01.2005, 27.05.2005 您可在以下网站发现本列表最新版:http://www.linuxrsp.ru/win-lin-soft/ ...

随机推荐

  1. day91-redis

    Redis数据库 简介 redis是一个key-value存储系统.和Memcached类似,它支持存储的value类型相对更多,包括string(字符串).list(链表).set(集合).zset ...

  2. 错误 103 未能加载文件或程序集“Telerik.Web.UI”或它的某一个依赖项。磁盘空间不足。 (异常来自 HRESULT:0x80070070)

    运行vs2010时出现错误: 错误 103 未能加载文件或程序集“Telerik.Web.UI”或它的某一个依赖项.磁盘空间不足. (异常来自 HRESULT:0x80070070) 处理方式:清理C ...

  3. LDAP2-创建OU创建用户

    创建OU创建用户 1.创建OU 选择Organisational unit 组织单元 输入OU名称 提交信息 结果创建成功 2.创建员工 选择ou选择新建子条目 选择默认模板 选择inetorgper ...

  4. 如何备份和恢复你的TFS服务器(三)

    进行一次备份 当然,如果你已经建立了一个时间表,那么备份会在指定的时间自动地进行,但是我真的无法给你展示一张很酷的截图——那是不可见的:).无论你是否建立了一个时间表.你都可以在任意时间执行一次完整的 ...

  5. odoo 11 之signup_with_phone模块分析

    signup_with_phone模块的主要功能是允许用户用自己的手机号作为注册登录账号,这里会进行手机号码格式的严格检查,该模块依赖odoo自带的auth_signup注册模块. 该项目地址在htt ...

  6. C#发邮件_EmailHelper

    EmailHelper类 public class EmailHelper { /// <summary> /// 发送邮件 /// </summary> /// <pa ...

  7. H5 字符实体

    41-字符实体 (greater than) © 版权符号 --> 我   爱你 到此为止我们的HTML的基础标签就学习完毕了, 例如我们学习了<h1>标签, <table&g ...

  8. Survey项目总结

    1.Ioc深入理解 Inverse of control org.springframework.scheduling.quartz.SchedulerFactoryBean org.mybatis. ...

  9. python的UnboundLocalError: local variable 'xxx' referenced b

    一.意思: 本地变量xxx引用前没定义. 二.错误原因     在于python没有变量的声明 , 所以它通过一个简单的规则找出变量的范围 :如果有一个函数内部的变量赋值 ,该变量被认为是本地的,所以 ...

  10. html总结:表格中的文字居中

    <style> table { text-align:center; } </style>