在 .net core 与 .net framework 应用之间共享库

如果你对 .net core 做了任何重要的提交，你就需要为 .net framework 共享同样的库，因为，.net core 是一个新兴的系统生态系统，仍然缺失很多部分。

在混合系统中，你有两个选项来共享库。首先，你可以开发一个 .net 标准库，只要版本匹配，就可以直接共享。或者，你可以使用多目标方式对多于一个的平台进行交叉编译。

通过 .NET Standard 方式共享

Microsoft 引入了 .NET Standard 以提供在微软生态下的公共标准。它可以看作是可移植类库 PCL 的后继者，简化了针对不同平台的业务。在PCL 基于平台能力的配置中， .NET Standard 提供了精心选择的 API 集。

结果就是你可以创建可以直接用于 .NET Framework 和 .net core 的库（甚至包括 Xamarin ）。你只需要确保 .NET Standard 库的 Nuget 包添加到 .NET 应用中。

现在已经有半打的 .NET Standard 存在，所以并不能立即搞清楚目标版本，感觉走了 DLL 地狱，来了 .NET Standard 地狱。简单来说，越高版本的 .NET Standard 就提供越多的 API 可用，而越低的版本支持的平台越多。

与任何 .net core 迁移过程一样，你将是依赖项的囚徒，尽管适配 .NET Standard 的公共库越来越多，对低于 1.3 的支持相当有限，从实践的角度来说，你可以从 .NET Framework 4.6 开始。

许多开发者在产品中有混合的 .NET Framework 版本。这使得适配 .NET Standard 相当困难，特别是大型系统。你会惊讶于在黑暗的角落中有如此多的 .NET 4.0 甚至 .NET 3.5 代码。尽管 4.5.2 仍然被微软支持，但是它仅限于 .NET Standard 1.2.

多目标

对于无法保证特定版本的 .NET Framework 的混乱系统来说，多目标可以帮助扩大共享库的范围。这允许你编译单个的本地相关，而对生成 .NET Standard 版本和你需要的 .NET Framework 版本。尽管代价是你需要管理多组的编译输出。

从 VS 2017 开始，这变得更加直接。

多版本的体验并不一致，在 VS 2015 中，使用老式的基于 JSON 的 xproj 格式。可以为一个项目选择多个框架，但是无法在 .NET Framework 项目中引用。需要采用一些非常困难的技巧：要么将项目迁移到 xproj 结构中，要么使用 NuGet 发布，两种方式都不理想。

在新的版本中，这个问题已经得到了解决，但你仍然需要手动编辑项目文件以使其工作。在手工修改 framework 之后建议重新加载解决方案。

下面的示例展示了如何调整 TargetFramework 元素以使项目编译到多于一个的 framework

<PropertyGroup>

  <TargetFrameworks>net452;netstandard1.3</TargetFrameworks>

</PropertyGroup>

在编译项目的时候，你将发到在 bin 文件夹中有两个输出，每个都是 framework 特定的。这使得你可以创建生成共享程序集的项目，针对 .NET Framework 4.5.2 或者任何 .NET Core 1.0

迁移现有库

在规划共享库的时候，应牢记 .NET Standard 是基于 .NET Framework 的一个子集。您已经习惯在 .NET Framework 中使用的许多 API 不是 .NET Standard 的一部分了。特别是被 .net core 重构的领域中。

将现有的 .NET Framework 库实现为 .NET Standard 库不可避免地需要迁移，类似于移植到 .net core 。微软的 API 迁移工具可以告诉你这将需要涉及多少工作。这个命令行工具，ekyi为你提供导致兼容性问题的类型和成员的详细信息。某些情况下，需要特定版本的 .NET Standard ，某些情况则不支持。

重复一下，最大的困难可能是外部的依赖库。多目标方式仅仅可以用于，在项目的所有依赖支持你的目标框架的时候。某些差异可以通过条件编译进行平滑处理，但是，.NET Standard 的主要意图之一就是消除此类变通的方法。

很快...... 统一和兼容垫片

共享代码的所有问题将由 .NET Standard 2.0 标准更为容易处理。该版本允诺将提供单个 API 集合，支持跨 .NET Core 2.0、.NET Framework 4.6.1 和 Xamarin。承诺提供一个兼容性的垫片，将支持 .NET Framework 程序集直接用于 .NET Standard 库。例外是对不受 .NET Standard 支持的 API 的旧的 framework 版本或者程序集，是行不通的。

尽管有这样的限制，微软认为，在 Nuget 中超过 60% 的常用 .net framework 包可以通过垫片兼容 .NET Standard。这使得遗留的 .net framework 库将可以通过 .net standard 兼容。

永远不能共享的部分

尽管 .NET Standard 2.0 承诺的标准日益增强，但是仍然有一些领域永远不会成为 .net core 的一部分。作为 Windows 通用应用的新 UI 原则， Windows Form 和 WPF 将永远保留在 .net framework 中，任何平台特定的内容将被排除在外。例如，你不能使用 .net core 构建 Windows 服务，或者平台特定的进程管理器，例如 windows 中的 NSSM 或者 Linux 中的超级用户。

WCF 的命运有点含糊，仍然有一个团队在开发，但是看起来并不重要。对于在 WCF 中进行了大量投资的人来说不是好消息。这可能会造成体系的屏障，将比一对 .net framework 依赖更难解决。

原文地址

http://www.ben-morris.com/sharing-libraries-between-net-core-and-net-framework-applications/