c# - 是否有任何可靠的(甚至是标准化的)方法来创建同时支持多个目标框架的 .NET 库？

Question

我知道这是一个很普遍的问题，但我一直无法找到解决以下情况的可靠资源，也没有找到一个地方。所以我决定在这里提问，希望能帮助其他在同样问题上苦苦挣扎的人:

作为 .NET 组件的开发人员，我希望支持各种 .NET 目标框架。随着最近引入dot net core 和dot net standard 目标框架变体的爆炸式增长，这个话题对我来说变得非常重要。

因此，假设我正在编写一个编译为 MyLib.dll 的 C# 库 MyLib(我将其称为“产品”)。我想支持不同范围的目标框架:net35、net40、net45、netstandard1.2 等. 因此，我为每个目标框架创建构建(MSBuild 或 csproj 文件)并将它们捆绑在一个 nuget 包中，遵守 nuget guidelines for the lib folder structure .因此，产品可以从单个构建工件——nuget 包中获得。

对于每个目标框架版本，我都尝试利用它的特性和优势，并为较低版本提供 pollyfills 或剥离一些特性。一般来说，无论使用项目的目标框架如何，“产品”都是可用的——我的意思是 MyLib 的 nuget 包应该正确安装，并且应该引用适当的 dll。

所以，出现了几个问题:

• 在不同的版本之间共享相同的程序集版本信息是否正确？喜欢重复使用相同的 AssemblyInfo.cs 文件吗？
• 哪些程序集属性不应在我的构建之间共享？我已经开始another thread关于 [assembly: Guid("...")]] 属性。其他人是displaying concerns [assembly: AssemblyTitle("...")] 属性，但在不同的上下文中。
• 是否有任何好的或标准化的方法来组织解决方案来支持上述构建结果。那里的大多数项目是否真的在实现这一目标的过程中自谋生路？

到目前为止，我自己的方法是为同一“产品”的每个目标框架使用单独的 .csproj 文件，但随着开发的进行，支持多个项目可能会变得乏味，即使目标框架数量相当多现在很重要。

Answer 1

Therefore I create builds (MSBuild or csproj files) for each target framework and bundle them together in a single nuget package.

如果您使用的是 Visual Studio 2017 中新的 csproj“SDK”格式，那么您甚至不需要这样做 - 它支持多个目标框架。例如:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
   <TargetFrameworks>net451;netstandard1.3</TargetFrameworks>
  </PropertyGroup>
</Project>

该项目同时支持 .NET Framework 4.5.1 和 NETStandard1.3。

这会自动创建条件编译符号，因此您可以执行 #if NET451 或 #if NETSTANDARD1_3 之类的操作，以便在需要时有条件地应用代码。您同样可以在 .csproj 本身中执行此操作，以便仅包含一个框架的 nuget 包。 Dapper项目在他们的 .csproj 文件中有一个这样的例子。

使用新的 dotnet cli，您可以使用 dotnet pack 将其全部打包到一个 nuget 包中。